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PREFACE 



Preface 



This publication is a reference manual for the 
p-System, It covers the internal details of the 
p-System. The p-machine architecture and 

instruction set are covered. Code file format, 
low-level I/O mechanisms, and operating system 
details are also addressed. 

For further information about the system and its 
use, refer to the following publications: 

Personal Computing with the UCSD p-System 
Operating System Reference Manual 
Program Development Reference Manual 
Assembler Reference Manual 
Optional Products Reference Manual 
Adaptable System Installation Manual 
UCSD Pascal Handbook 
FORTRAN-77 Reference Manual 
BASIC Reference Manual 
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CHAPTER 1 
INTRODUCTION 



Introduction 



PURPOSE OF THIS MANUAL 

This manual describes the internal design of the 
p-System®. The coverage includes the p-machine, 
operating system, basic I/O, and the way in whieh 
these elements are organized to support the running 
of a program written in UCSD Pascal®, BASIC, or 
FORTRAN-77. 



It should serve as a guide and reference for more 
advanced users of the p-System, but isn't intended 
to be a stand-alone definition for the use of 
implementors. Such a definition doesn't yet exist; 
if one is written, it will probably be based on the 
format of this book. 



Ferhaps the best way to use this manual is to read 
it sequentially, skipping those sections (such as the 
list of p-codes) that go into very specific detail. 
This should give the reader a fairly complete 
picture of what goes on within the p-System. If 
the user then needs to know specific internal 
details, the relevant section can be referred to 
lfltpp. 



While few users will want or need to implement a 
p-System from scratch, the internal descriptions 
provided in this guide should be useful to a number 
of audiences. 
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The largest audience is probably those who will 
make no specific use of the information. To these 
users, the benefit will be a better understanding of 
the p-System's operation and a general improvement 
in their ability to engineer programs for effective 
execution in the p-System environment. 

Second, there are the implementors of system 
software facilities that complement existing 
p-System capabilities; for instance, new language 
translators, new system utilities, or p-machine 
emulators (PMEs) for additional processors. For 
this group of programmers, the Internal 
Architecture Reference Manual presents more 
information than was available in the past. 

Finally, there are the implementors with a 
compelling need to use facilities such as the ability 
to explicitly generate p-codes in a Pascal program, 
where an ordinary Pascal construct wouldn't suffice 
(we take it for granted that only a compelling need 
would lead you to take such steps). 

All of these audiences (but particularly the last) 
should understand that the principal commitment of 
SofTech Microsystems (and its licensees) is to the 
user facilities, and not to any of the specific 
implementation strategies that are described in this 
guide. Programmers who take advantage of 

"internal tricks" do so at their own risk. 
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A BRIEF HISTORY OF THE SYSTEM 

The software system that is now called the 
p-System began when Kenneth Bowles was 
responsible for teaching the introductory 
programming course at the University of California, 
San Diego. In late 1974, under Bowies' direction, a 
group of undergraduate and graduate students began 
to implement Pascal for microcomputers. 

Before this time, the introductory programming 
course had been taught using a large time-shared 
computer. This presented a bottleneck— many 

people used the. machine, so its turnaround was 
sometimes quite slow, and a student's productivity 
was to some extent limited by the availability of 
the card punches. Furthermore, the machine's 
time-sharing environment, its accounting system, its 
complexity, and the amount of sensitive information 
that it stored prevented the student from any 
extensive "hands on" use of the machine or its 
facilities. In brief, the computer was intimidating. 



0400101:01A 1-5 



Introduction 



These were the main reasons for the decision to 
change the nature of the beginning programming 
course. It would be self-paced, to accommodate 
the large number of students, and each individual 
student's study habits (UC— Irvine's physics program 
had been doing this successfully for a couple of 
years). It would use Pascal, rather than the 
dialect of Algol that was specific to the 
University's large time-sharing computer; and, it 
would use microcomputers. 

The decision to use small computers was motivated 
partly by their low cost, and partly by the desire 
to give students an opportunity to program in an 
interactive environment. The system was first 
implemented for a number of PDP-11/1 0's with 
floppy disks and VT-50 terminals. Students were 
expected to buy their own floppy disk, and use it 
for storing the system and their own programs. 

It was the interactive environment that led to some 
of UCSD Pascal's deviations from the standard 
language, mostly as regards INTERACTIVE files and 
the handling of EOF and EOLN. The type STRING 
came about from the desire to teach basic 
programming concepts without recourse to numerical 
problems (which distracted many students from the 
actual problems of programming). 
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The user interface of the p-System, by which we 
mean the philosophy of displaying a menu or prompt 
at every level of the p-System, and organizing them 
in a tree structure, was intended to be easy to 
learn for the complete novice, yet usable (that is, 
not cumbersome) for the experienced user. This 
proved very successful, and has been retained. 

The emulative approach to executing Pascal was 
present from the beginning. P-code, adapted from 
the original design by Urs Amman of the 
"Eidgenossische Technische Hochschule," in Zurich, 
was designed to be compact and easily generated 
by a compiler; because of the constraints of the 
microprocessor environment, the goal was to keep 
the compiler and the code files as small as 
possible. The tradeoff in execution time was felt 
to be an affordable cost (time has borne out this 
decision). 

All of the original implementations were on 
PDP-ll/LSI-11 machines. Because of the emulative 
approach, it was a relatively straightforward matter 
to rewrite the p-machine emulator for the 8080 and 
Z80, and subsequently, for many other processors. 
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This adaptation of the PME (sometimes called the 
interpreter) was originally motivated by the search 
for less expensive hardware, but it was soon 
recognized that software portability was valuable in 
itself. The economics of the computer business, 
especially the microprocessor field, dictated this. 
It isn't a new observation that hardware costs 
continue to plummet, while software, being 
"hand-made," continues to be very expensive; it is 
relatively new to encounter a software system that, 
through modularity and portability, addresses the 
problem as thoroughly as does the p-System. 
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FORMAT 



Code File Format 



INTRODUCTION 

This chapter describes the internal format of 
p-System code files. Code files may contain either 
p-code or native code. P-code is the output of the 
compilers and is described in Chapter 3. Native 
code is specific to a particular processor and is 
output by the assemblers and the Native Code 
Generator. Code files also contain various sorts of 
"housekeeping" information. 



CODE SEGMENTS 

A code segment is a section of executable code 
which is brought into memory as a whole unit. 
Each segment consists of a collection of routines 
(procedures, functions, and so forth), together with 
descriptive information. The code and information 
in a segment are contiguous since the code segment 
is the "unit of movement" for code. 

There are up to 255 routines within a segment, 
numbered 1 through 255» 

At compile time, segments are assigned a name and 
a number. The name is eight characters long. It 
is used by the operating system to handle 
intersegment references at associate time. 
(Associate time is the time it takes the operating 
system to stitch together the units referenced by a 
program.) It is also used when maintaining code 
files with LIBRARY. The number is used to 
reference the segment at run-time. 
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The beginning (low address) of a code segment is a 
record that contains the following information about 
the segment: 

pointer to the procedure dictionary 

pointer to the relocation list 

the eight character name of the segment (four words) 

byte sex indicator 

pointer to the constant pool 

real size indicator 

space reserved for future use (two words) 

Figure 2-1 illustrates a code segment as it would 
be loaded into memory. The various substructures 
of a code segment are described below. Note that 
all fields within a code segment are word-aligned. 
Also, all intersegment pointers are word offsets 
from the base of the segment. 
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Figure 2-1. Executable Code Segment Format 
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Code Segments and Byte Sex 

Code segments are independent of the byte sex 
of the host processor. A number of system 
components cooperate to achieve this 
independence. 

There are two groups of word-oriented 
(byte-sex-dependent) information. The first is 
superstructure information, such as the routine 
dictionary. This information is flipped by the 
operating system when a segment is loaded. The 
second is embedded information, such as constants 
(accessed by the Load Constant (LDC) p-machine 
instruction or by Case Jump (XJP) tables). This 
sort of information is flipped by the PME. 

The compiler produces code segments that contain 
word information in the natural order of the 
machine on which the compiler is run. 
Immediately following the segment's 8 character 
name is a flag that always contains the constant 
1, in the byte sex of the original machine; if 
read in the opposite byte sex, it appears to be 
256. 

When a segment is loaded by the operating 
system, and its byte sex flag indicates that the 
sex of the segment is opposite that of the 
running machine, the segment superstructure is 
byte-swapped. Embedded information is then 
flipped by the PME. 

The net result is that segments of either sex can 
run on any machine. 
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Routine Dictionary 

The first word in a code segment points to word 
of the segment's routine dictionary (also called 
the "procedure dictionary"). The routine 

dictionary is a list of pointers to the code for 
each routine in the segment. Each routine 
dictionary pointer is a segment relative word 
pointer. 

Routines within a segment are numbered 1 
through 255. A routine's number is a negative 
index into the routine dictionary; the n'th word 
in the dictionary contains a pointer to the code 
for routine n. 

The first word (word 0) of the dictionary 
contains the number of routines in the segment. 

In the case of EXTERNAL and FORWARD 
routines, the source code may contain a routine's 
declaration but not its code. The corresponding 
routine dictionary entry is zero (at least, before 
linking 1 ). 



Routine Code 

The code of a routine consists of two words: 
Data_Size and Exit_IC, followed by the 
executable object code. The object code may be 
entirely p-code, entirely native code, or a 
mixture of the two. 
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Data_Size is the number of words of local data 
space that must be allocated when the procedure 
is called. Data_Size doesn't include parameters; 
the routine's parameters are assumed to already 
be on the stack. The first executable instruction 
starts at the word immediately following the 
Data_Size word. If the first executable 

instruction is native code, Data_Size is negative. 
No local data space is allocated for assembly 
language procedures. 

If this first instruction is a p-code instruction, 
then Exit_IC is a segment relative byte pointer 
to the code that must be executed when the 
procedure is exited. Otherwise, Exit_IC is 

undefined at run-time. 

If the code of the routine contains both p-code 
and native code, it is still the first instruction of 
the routine that determines these conditions. 
Procedure code produced by a Native Code 
Generator always starts with a p-code. Thus, 
Data_Size and Exit_IC are defined as in a 
procedure which consists entirely of p-code. 



The Constant Pool/Real Constants 

Multi-word constants are stored together in a 
single constant pool for the entire segment. The 
constant pool begins immediately after the last 
body of procedure code in the segment. 
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The location of the constant pool is contained in 
the constant pool pointer, a segment relative 
word pointer that immediately follows the byte 
sex indicator word at the beginning of the 
segment; it points to the low address of the 
constant pool. If the constant pool pointer is 
equal to zero, the segment doesn't contain a 
constant pool. 

Constants are referenced by word offsets relative 
to the beginning (low address) of the constant 
pool. 

The constant pool is divided into two subpools: 
the real pool and the main pool. 

TT-if* ■Pll»e+ T*/r\T»/"! />•£ +Vli-» rtrtno+nnf r±r\nl n ^in4-ri 4-« +1-.-.. 
jlaiC XJ.JLOL. ivwiu \J±. LllC Cl/UOlCUll pOuJ. ^WAlIta LU lilC 

beginning of the real pool. This is a word 
pointer relative to the start of the constant pool; 
if there are no real constants in the code 
segment, this word will be 0. The first word of 
the real pool contains the number of real 
constants in the real pool. 

Figure 2-2 illustrates a constant pool with an 
embedded real subpool. 
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Figure 2-2. Constant Pool 
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Real constants are compiled into a 
processor-independent ("canonical") format and are 
converted, at segment load-time, into a 
processor-specific internal format. Real 

constants are generated as either 2-word (32-bit) 
or 4-word (64-bit) floating point data formats. 
Code files containing real constants can be 
transported across all p-System implementations 
which use the same real size. In order to 
transport them to a machine using a different 
real size, they must be recompiled. Within a 
single program, all compilation units must share 
the same size for real values. 

The default real size of a code file created by 
the compiler is determined by the p-machine 
emulator in use at compile-time. The $R 

compiler directive ma^ override this default, 
however. 



The real size at compilation time is embedded in 
every code segment (even though it may not 
reference any reals). The Real_Size word at the 
base of the segment contains this value. 
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A 32-bit real constant is represented by a 
three-word record. The first word contains a 
signed integer representing the exponent value. 
The following two words contain the mantissa 
digits. A mantissa word representing significant 
mantissa digits contains an integer whose absolute 
value is between and 9999; its value 
corresponds to four mantissa digits. The first 
mantissa word is signed and, thus, contains the 
mantissa sign. The second mantissa word may 
contain a negative value; in this case, it doesn't 
contain any significant digits and is disregarded 
when constructing the internal representation of 
the real constant. It serves as a terminator 
word for the constant conversion routines. The 
decimal point is defined to lie to the right of 
the four digits in the last valid (used) mantissa 
word. The digits in the last mantissa word are 
left-justified. For example, if the real value is 
1.1, the first mantissa word contains 1100 
decimal (or 044C hexadecimal). 
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Example: 

1..4 significant mantissa digits: 

The first mantissa word contains a signed 
value between and 9999. The second 
word contains a negative value. The 

implied decimal point position is at the end 
of the first word. 

5..8 significant mantissa digits: 

The second mantissa word contains a 
positive value between 1 and 9999, and 
represents up to four low-order digits. The 
first word contains a signed value between 
1 and 9999; it represents the four 
high-order digits. The implied decimal point 
position is at the end of the second word. 
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A 64-bit real constant is represented by a reeord 
whose length may vary between four and six 
words, depending upon the number of significant 
digits in the constant. The first two words of a 
64-bit constant are identical in format to those 
of a 32-bit real constant; thus, the format always 
contains an exponent word and a first mantissa 
word. An enumeration of the remaining words 
for all cases follows: 

1..4 significant mantissa digits: 

Mantissa word 2 contains a negative 
terminator. Word 3 is zeroed and is present 
solely to provide sufficient space for the 
native format. 

5..8 significant mantissa digits: 

Mantissa word 2 contains 1 to four digits 
(left-justified). Word 3 contains a negative 
terminator. 

9..12 significant mantissa digits: 

Mantissa word 2 contain four digits. Word 3 
contains one to four digits (left-justified). 
Word 4 contains a negative terminator. 

13. .16 significant mantissa digits: 

Mantissa words 2 — 3 contain four digits. 
Word 4 contains one to four digits. Word 5 
contains a negative terminator. 

17..20 significant mantissa digits: 

Mantissa words 2 — 4 contain four digits. 
Word 5 contains one to four digits. 
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Real constants are converted to native 
machine format when a code segment is loaded 
into memory; this may result in a significant 
run-time overhead for programs that are 
memory bound. Time-critical programs of this 
nature may sacrifice portability for execution 
speed by using Real Convert utility to convert 
their real subpools into native machine format 
within the code file itself. This is done by 
replacing the canonical form of each real 
constant in the code file with a native real 
constant. The modified subpool is merged with 
the main pool by setting the real pool pointer 
to zero, thus eliminating the usual conversion 
process during a segment load. Because the 
constant pool is transformed in place, constant 
offsets embedded in the code file don't require 
updating. (This, of course, reduces the 

portability of the program.) 



The Relocation List 

The last (high address) body of information in a 
code segment is the relocation list. The second 
pointer at the beginning of the code segment 
points to the last (highest address) word in the 
relocation list. This pointer is a segment 

relative word pointer; if there is no relocation 
list, it is equal to zero. 
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The relocation list contains all the information 
necessary to fix any absolute addresses used by 
code within the segment, whenever the segment 
is loaded or moved in memory. Such absolute 
addresses are needed only by native code. 
Segments containing exclusively p-code are 
completely position-independent; no relocation list 
is needed. 

A relocation list consists of zero or more 

relocation sublists. Each sublist contains code 

offsets for objects that must be relocated, and 

specifies the type of relocation that must be 

done. Sublists can occur in any order, and more 
than one sublist can have the same type of 
relocation. 

The following code fragment shows the format of 
the heading of a sublist: 



Loc_Types= (Reloc_End, (signals end of entire relocation list} 

Seg_Rel, (relative to address of base of this segment) 
Base_Rei, {relative to data segment given in DATASEGNUMt 
Interp_Rel, (relative to PHE's interp-relative table) 
Proc_Rel) ; (relative to address of 1st instruction in proc) 

List_Header=PACKED RECORD 

List_Size: integer; (number of pointers in sublist) 
Data_Seg_Num: 0..255; (local segment number for Base_Rel) 
Reloc_Type: Loc_Types; (relocation type of sublist entries) 
END; 



Each sublist contains a List_Header and zero or 
more segment relative byte pointers to the 
objects which must be relocated. The 

Reloc_Type field in the List_Header defines what 
kind of relocation will be applied to all objects 
designated by the sublist. 
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The relocation type Proc_Rel is generated by the 
assembler, but is changed by the linker into 
Seg_Rel. Proc_Rel sublists should never be 
encountered when loading and relocating assembly 
code. 

The Data_Seg_Num field in the List_Keader is 
only used in sublists with a Reloc_Type of 
Base_Rel, and in all other cases should be 
zeroed. It specifies the local segment number of 
the data segment to which all the sublist's 
pointers are relative. Since the assembler can't 
know this segment number in advance, it should 
zero-fill the field and leave the responsibility for 
correctly setting this field to the linker. 

The List_Size field in the List_Header contains 
the number of pointers in the sublist. 

Figure 2-3 illustrates a relocation list with 
multiple sublists. 
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The relocation list is intended to be used from 
high address down to low address. Each sublist 
in turn is processed from high to low until a 
sublist with a relocation type of Reloc_End is 
encountered. The Data_Seg_Num and List_Size 
should be for this terminating entry. 

The relocation list is located at the end of the 
code segment, since it is sometimes possible to 
discard the relocation information after the 
segment has been loaded into memory. 



Segment Reference List 

In the p-machine (described in the next chapter), 
each code segment is associated at run-time with 
an "environment vector" that defines the mapping 
of each segment number to the segment or unit 
that it designates. Each compilation unit has its 
own independent (that is, local ) series of segment 
numbers, and its own environment vector. In this 
way, a particular unit may be referenced by more 
than one unit, and each unit that references it 

mm. «. n ^ « »*££,-**»«»-.+ .-,«.-«-~»~».+ •*.. M I^**« ^Hff«„~ 
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about environment vectors appears in the section, 
"Code Segment Environments" in the next 
chapter.) 
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When a compilation unit references one or more 
other compilation units, the principal segment of 
the compilation contains a segment reference list. 
This list defines the connection between the 
segment numbers that appear in the object code 
(they are created by the compiler), and the 
names of the units to which they refer. Only 
principal segments contain segment reference 
lists. 

The segment reference list, when present, is 
located above the relocation list (it grows toward 
higher memory addresses). The list is used by 
the operating system at associate time. It 
doesn't occupy any space in memory during the 
program's execution (since the segment length 
field doesn't include it). 

The segment reference list associates the name 
of each compilation unit (which doesn't change) 
with the number by which that that compilation 
unit is referenced. 

The following fragment of Pascal code describes 
a record in the segment reference list: 



Seg_Rec= PACKED RECORD 

Seg_Name: PACKED ARRAY [0..7] OF CHAR; {referenced segment name) 
Seg„Num: 0..255; {associated segment number} 
Filler: 0..255; {reserved for future use) 
END; 
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The Seg_Refs entry in the segment dictionary 
(described below) contains the number of words in 
the segment reference list. The Code_Leng field 
in the segment dictionary can be used as a 
segment relative word pointer to the start of the 
segment reference list. The segment reference 
list consists of one or more Seg_Ree's, starting 
directly above the relocation lists (or procedure 
dictionary) and continuing towards higher memory 
addresses. A Seg_Rec consists of Seg_Name, 
which contains the name of the segment; 
Seg_Num, which contains the number by which 
the segment is referenced within this current 
code segment; and some filler. 

The segment reference list is terminated by a 
Seg_Rec with a blank-filled Seg_Name and 
Seg_Num of zero. 

Seg_Rec's with a Seg_Name of '***' are 
generated so that the operating system can 
execute the initialization and termination code 
sections of a unit. Before executing a host 
program, the operating system constructs a list of 
ail units used that contain a reference to ! *** ! , 
and uses this list to execute the 
initialization/termination sections of all such units 
before/after the host program is invoked. 
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When the initialization/termination section of a 
unit (which is procedure 1) is compiled, the 
following instruction is emitted between the 
initialization and termination parts: 



CXG <***'s Seg_Num>, 1 

where CXG is the p-code representation of a 
global procedure call. A local segment number is 
reserved for the r ***' segment reference, and the 
operating system creates a linear list that links 
together the units of a program that require 
initialization. At the end of this list is the 
outer body of the main program. The operating 
system invokes the program by calling the first 
initialization code on this list, which calls the 
next, and so forth up to the body of the main 
program. When the main program terminates, the 
calling chain is "popped," and termination sections 
are executed in the reverse order. 



Linker Information 

Linker information is a portion of a code segment 
that allows the linker to resolve references 
between p-code and native code. Segments 

output by an assembler always have linker 
information. Segments output by a compiler have 
linker information only if they contain an 
EXTERNAL routine. Only principal segments may 
contain EXTERNAL routines. 
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Linker information is a sequence of 8-word 
records, starting on the block boundary following 
the end (high address) of the segment reference 
list. The end of the sequence contains the value 
EOF_Mark. Linker information records are 

always eight words long; unused records and 
unused fields are zero-filled. 

If a code segment has linker information, the 
Has_Linker_Info boolean in Seg_Misc in the 
segment dictionary is TRUE. The starting block 
of linker information, relative to the start of the 
code file, can be calculated from the formula: 

Code^Addr + ( (Code_Leng + Seg_Refs + 255) DIV 256) 

where Code_Addr, Code_Leng, and Seg_Refs are 
all values in the segment dictionary (see below). 

Two fields are common to all linker information 
records. The Name field contains an 8-character 
segment name. The LI_Type field determines the 
nature of the linker information in the remainder 

V/J. Hit 1 <v WwTJL VJ« 
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The following fragment of psuedo-Paseal code 
describes a linker information record: 



Ptr_Rec_Num = {an integral number of 8-word pointer records} 
{this is variable from record to record}; 

LI_Types = (EOF_Mark, Glob_Ref, Publ_Ref, Priv_Ref, Const_Ref, 
Glob_Def, Publ_Def, Const_Def, Ext_Proc, Ext_Func, 
Sep_Proc, Sep_Func) ; 

LI_Entry = RECORD 

Name: PACKED ARRAY [0..7] OF CHAR; 
CASE LI_Type: LI_Types OF 

Glob_Ref, Publ_Ref, Const_Ref 

: (Format: (Word, Byte, Big); 
N_Refs: integer) ; 

Priv_Ref: (Format: (Word, Byte, Big); 
N_Refs: integer; 
N_Words: integer) ; 

Ext_Proc, Ext_Func 

: (Src_Proc: integer; 
N_Params: integer); 

Sep_Proc, Sep_Func 

: (Src_Proc: integer; 

N_Params: integer; 

Kool_Bit: boolean); 

Glob_Def: !Home_Proc: integer; 
IC_Offset: integer); 

Publ_Def: (Base_Offset: integer; 

Pub Data Seg: integer): 

Const_Def: (Const_Val: integer); 

EOF_Hark: 
END {CASE}; 

Ptr_List: ARRAYIO. . Ptr_Rec_Num] OF 
ARRAY [0..71 OF integer 

END {LI_Entry}; 
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Glob_Ref, Publ_Ref, Const_Ref, and Priv_Ref are 
linker information types generated by an 
assembler. Each consists of two fields that 
precede a list (Ptr_List) of segment relative byte 
pointers into the associated segment. Format 
contains the size of the fields pointed to by the 
accompanying list. N_Refs contains the number 
of pointers in the list. Ptr_List contains 

multiples of eight words; all unused words should 
be zero. 

For these types of linker information records, 
Ptr_Rec_Num = ceiling(N_Refs/8), where ceiling(n) 
is the smallest integer >= n. 

Glob_Ref is used to link identifiers in two or 
more assembled routines. Name is an identifier 
that is referenced within the segment and defined 
in some other assembled routine. Format should 
always be word. The linker must add the final 
segment offset of the referenced object to all 
words pointed at by Ptr_List. This offset must 
be in the correct addressing mode, that is, in 
bytes or words, depending on the processor being 
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Publ_Ref is used to link an identifier in an 
assembled routine to a global variable in a 
compilation unit. Name is an identifier that is 
referenced in the segment and defined as a 
global variable in some other compilation unit. 
Format should always be word. The linker must 
add the offset of the referenced object to all 
words pointed at by Ptr_List. 

Const_Ref is used to link an identifier in an 
assembled routine to a global constant in a 
compilation unit. Name is an identifier that is 
referenced in the segment, and defined as a 
global constant in some compilation unit. Format 
may be either byte or word. The linker must 
place the constant value into all locations 
pointed at by Ptr_List. 

Priv_Ref is used to allocate space in the global 
data segment. Format should always be word. 
N_Words specifies the number of words to 
allocate. The linker must add the offset of the 
start of the allocated area within the global data 
segment to all words pointed at by Ptr_List. 

Ext_Proc and Ext_Func are generated by a 
compiler to reference EXTERNAL routines. 
There is no PtrJList. Src_Proc is the number 
assigned to the routine. N_Params is the number 
of words allocated for parameter passing. 
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Sep_Proc and Sep_Func are generated by an 
assembler for routine declarations. There is no 
Ptr_List. Src_Proc is the number assigned to the 
routine. N_Params is the number of words 
allocated for parameter passing. Kool_Bit is 
TRUE if the routine is relocatable, and FALSE 
otherwise. Thus, with Kool_Bit = FALSE, and 
.RELPROC and .RELFUNC generate Sep_Proc or 
SepFune records with Kool_Bit = TRUE. 

Glob_Def declares a global identifier in an 
assembled routine. A Glob_Def record is 

generated for each label defined by a .DEF, 
.PROC, .FUNC, .RELPROC, or .RELFUNC 
directive. There is no PtrJList. Name is an 
identifier defined within the segment, and may be 
referenced by any other assembled routines within 
the same segment. Home_Proc contains the 
number of the routine in which Name is defined. 
ICJDffset is a byte offset to Name, relative to 
the start of the routine in which Name is 
defined. 

Publ_Def declares a global variable in a 
compilation unit. A Pubi_Def record is generated 
for each global variable in a compilation unit 
that is visible to any EXTERNAL routines. 
There is no PtrJList. Base_Offset is the word 
offset of the variable, relative to the start of 
the data segment that contains it. Pub_Data_Seg 
is the local number of the data segment that 
contains the variable. 
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Const_Def declares a global constant in a 
compilation unit. A Const_Def record is 
generated for each global constant in a 
compilation unit that is visible to any 
EXTERNAL routines. There is no Ptr_List. 
Const_Val contains the value of the constant. 

EOF_Mark indicates the end of used linker 
information records. Name should be blank-filled. 

The following table shows the types of segments 
(as defined in the segment dictionary), and the 
types of segment reference records that can be 
contained in the associated linker information. 
Note that Proc_Seg's can't have linker 
information at all. 
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CODE FILE ORGANIZATION 



The Segment Dictionary 

The first block of a code file contains the first 
record of that file's segment dictionary. A 
segment dictionary consists of a linked list of 
dictionary records; if the dictionary is longer 
than one record, subsequent records are embedded 
in the code file. These are each one block long, 
and are located between code segments. 

A single dictionary record can describe up to 16 
distinct segments. The information describing a 
segment is contained in six different arrays; the 
information describing a segment is found by 
using a single index value to select a component 
from each of these arrays. Entries in the 
segment dictionary describe only segments whose 
code bodies are included in the code file. 
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The following fragment of Pascal code describes 
a segment dictionary record: 

CONST Kax__Dic_Seg = 15; {maximum segment dictionary record entry} 

TYPE Seg_Dic_itange = 0. .Hax_Dic_Seg; {range for segment dictionary entries) 

Segment_Name ■ PACKED ARRAY 10.. 71 OF CHAR; (segment name) 

{segment types} 

Seg_Types = (No_Seg f {empty dictionary entry} 
Prog_Seg, {program outer segment} 
Unit_Seg, {unit outer segment} 

Proc_Seg, {segment procedure inside program or unit} 
Seprt_j5eg) ; {native code segment) 

{machine types} 

H_Types - <M_Psuedo, M_6809, M_PDP_11, M_8080, M_Z_80, 
1L_GA_440, H_6502 f M_6800, M^9900, 
M_8086, M_Z8000, M_68000, H_HP87) ; 

{p-machine versions) 

Versions = (Unknown, II, II_1, ill, IV, V, VI, VII}; 

{segment dictionary record} 
Seg_Dict - RECORD 
Disk_Info: 

ARRAY [Seg_Dic_RangeJ OF {disk info entries) 
RECORD 

Code_Addr: integer; {segment starting block) 
Code_Leng: integer; {number of words in segment) 
END {Of RECORD); 
Seg_Name : 

ARRAY [Seg_Dic_Rangel OF Segment_Name; {segment name entries) 
fleg_Misc : 

ARRAY [Seg_Dic_RangeI OF {misc entries) 

PACKED RECORD 

Seg_Type: Seg_Types; {segment type) 
Filler: 0..31; {reserved for future use) 

Has_Link_lnfo: boolean; {need to be linked?) 
Relocatable: boolean; {segment relocatable?) 
END {Of PACKED RECORD); 
Seg_Text : 

ARRAY [SegJDic_Range] OF integer; {start blk of interface text) 
Seg_info: 

ARRAY [Seg_Dic_Range] OF {segment information entries) 
PACKED RECORD 

Seg_Num: 0..255; {local segment number) 
MJType: M_Types; {machine type) 
Filler: 0..1; {reserved for future use} 

Hajor_Version: Versions; {p-machine version) 
END {Of PACKED RECORD); 

Seg__Famly: 

ARRAY [Seg_Dic_Range] OF {segment family entries) 
RECORD 

CASE Seg_Types OF 
Unit_Seg , Prog_Seg : 

(Data_Size: integer; {data size) 

Seg_Refs: integer; {segments in compilation unit) 
Hax_Seg_Num: integer; {number of segments in file) 
Text_Size: integer) ; {# of blks interface text) 
Seprt_Seg , Proc_Seg : 

(Prog__Name: Segment_Name) ; {outer program/unit name) 
END {of Seg_Famly}; 
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Next_Dict: integer? {block number of next dictionary record} 

Filler: ARRAY [1..2] OF integer; 

Checksum: integer; {see QuickStart in Chapter 6} 

Ped_Blk_Count : integer; {see QuickStart in Chapter 6} 
Part_JJumber: RECORD 

A, B: integer; 

END; 
Copy_Note: string(773; {copyright notice} 
Dict_Byte_Sex: integer; {machine sex (Sex =1)} 
END {of SEG_DICT); 

Disk_Info contains information about the 
segment's location within the file. Segment code 
always starts on a block boundary. Code_Addr is 
the number of the block where the segment code 
starts (relative to the start of the code file). 
Code_Leng is the number of 16-bit words in the 
segment. This size includes the relocation list 
but doesn't include the segment reference list. 
All unused entries in this array should be zeroed. 



Seg_Name contains the first eight characters of 
the program, unit, segment, or assembly procedure 
name. Unused entries should be blank-filled. 

Seg_Misc contains miscellaneous information about 
the segment. Seg_Type indicates the type of 
segment. Prog_Seg and Unit_Seg are outer 
segments oi programs anu unus, respectively. 
Proc_Seg is a segment routine within either a 
unit or a program outer segment. Seprt_Seg is 
an unlinked native code segment. Has_Link_Info 
indicates whether linker information has been 
generated for this segment. Linker information 
resides in the blocks that directly follow the 
segment reference list. Linker information starts 
on a block boundary. The Boolean Relocatable 
specifies whether a code segment is statically or 
dynamically relocatable. 
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Dynamically relocatable code segments reside in 
the code pool (described in the next chapter); 
their position in memory may change many times 
during execution. Statically relocatable code 
segments are loaded only once, in a fixed 
position on the system heap (also described in the 
next chapter); they remain position-locked and 
memory-locked throughout their lifetime. 

All segments that contain only p-code are 
position-independent and, thus, dynamically 
relocatable. Segments that contain native code 
may be dynamically relocatable provided they 
make no assumptions about either the lifetime of 
any modifications made to the segment body 
itself or to the exact location of the segment 
body in memory across the execution of a single 
p-code. 

Dynamically relocatable native code is generated 
by assembling routines using the RELPROC or 
RELFUNC assembler directives; a linked code 
segment containing assembler routines is 
dynamically relocatable only if all of its 
assembler routines were originally specified as 
dynamically relocatable. Note that the use of 
these assembler directives is an assertion by the 
programmer that the routines declared behave 
properly; the system doesn't enforce this, so 
caution must be used. If a routine is to be 
dynamically relocatable, you can't expect it to 
store information in the segment body, be 
self-modifying, or store pointers to the code 
segment in data variables, and then assume that 
things will proceed correctly the next time the 
routine is called. 
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The Boolean Relocatable is unaffected by the 
presence or absence of relocation lists, and isn't 
relevant to concurrency considerations. 

SegJText contains the starting bloek of the 
segment's INTERFACE text section, relative to 
the start of the code file. The INTERFACE text 
section can appear anywhere within the code file 
that contains the code segment it describes. The 
SegJText array entry, in conjunction with the 
Text_Size field in the Seg_Family record, 
indicates the address and length of the 
INTERFACE section in blocks. The INTERFACE 
text section always starts on a block boundary 
and follows all of the conventions of a text file 
with the exception that the last page of the 
section may be either one or two blocks long. 
Only segments with a SegJType of Unit_Seg have 
INTERFACE sections. All other segments and 
unused entries should be zero-filled. 

Seg_Info contains further information about the 
segment. Seg_Num is the segment number. 

M_Type tells what kind of object code is in the 
segment. If there is any native code in the 
segment, then M_Type will have one of the 
processor-specific MJType's. If the segment 

consists exclusively of p-code, then its M_Type is 
M_Psuedo. Major_Version gives the version of 
the p-machine on which the code file is intended 
to run. 
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Seg_Famly contains information about the code 
segment's compilation unit. The information 

contained in this array depends on whether 
Seg_Type indicates a principal or a subsidiary 
segment. 

If the segment is a subsidiary segment, then 
Seg_Famly contains the first eight characters of 
the parent compilation unit's name, stored in 
Prog_Name. If this name isn't known at code 
file generation time (as is the case with 
Seprt_Seg's), the field should be blank-filled. 

If the segment is a principal segment, then the 
information in Seg_Famly consists of four fields: 

■ Data_Size is the number of words in this 
segment's base data segment. The variables 
of principal segments are referenced from any 
location, including their own outer routine 
bodies, via global loads and stores (rather than 
local operations). Therefore, the Data_Size 
field associated with the body of an outer 
routine in a code segment should be zero, so 
that no superfluous memory will be allocated 
in an unused local data area. 

■ Seg_Refs is the size in words of the segment 
reference list for this segment. 

■ Max_Seg_Num is the total number of segment 
numbers assigned to this compilation unit. 
Max_Seg_Num includes all segments with 
assigned numbers, regardless of whether the 
segment body is contained in this file or not. 
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• Text_Size is the number of blocks of 
INTERFACE text within the compilation unit, 
Text_Size is used in conjunction with the 
Seg_Text array to specify the INTERFACE 
text for a compilation unit of type Unit_Seg; 
it is zero-filled for all other compilation unit 
types. 

If the segment is unused (Seg_Type = No_Seg), 
then Seg_Famly should be zero-filled. 

Next_Dict contains the block number of the next 
segment dictionary record, relative to the start 
of the code file. In the last record of the 
segment dictionary, Next_Dict should be zero. 

Part_Num contains the SofTech internal part 
number for the file. 



Filler is reserved for future use and should 
always be zero-filled. 



P/inu Nntp is rpsprveri fnr a nnrwiMarht moccncro 
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which can be created with either the LIBRARY 
utility or a compiler directive. 
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Sex corresponds to the byte sex of the segment 
dictionary. It is a full word that contains the 
value 1, with the same byte sex as the rest of 
the dictionary record. Thus, when this word is 
examined by a program running on a machine 
with the same byte sex as the code file, it will 
appear as a 1; on a machine of opposite sex, it 
will appear as a 256. System programs use this 
word to detect the sex of the dictionary, and, if 
necessary, byte-swap the word-oriented fields of 
the dictionary. 



Assembler-Generated Code Files 

Code files generated by an assembler have a 
slightly different structure from those generated 
by a compiler. A relocation list is generated for 
each procedure in an assembler-generated segment 
(instead of one relocation list for the whole 
segment). These are the only sort of lists that 
may contain Proc_Rel relocation. These lists are 

n1n AM y4 i ot *~ ~ AX r* +« 1„ A -P4-«_ 4-1 I J ~ i> 4.1 
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procedure they describe. The start or high end 
address of each list is pointed at by the segment 
relative word pointer contained in the Exit_IC 
field of each assembler-generated procedure. 
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An assembler-generated segment is also unique in 
that during the linking process, the code bodies 
of all its procedures and functions may be copied 
into one of the segments of the compilation unit 
to which it is being bound. Further, the name of 
the segment or segments that the assembly code 
may be linked to is never known at assembly 
time. It is, however, always assumed that any 
number of assembly procedures or functions that 
communicate via REFs and DEFs are always 
bound into the same segment, regardless of 
whether they were assembled together. 

The Data_Size word generated by the assembler 
for each routine should have a value of -1 
(OFFFF HEX); this indicates a data size of zero 
that is one's complemented, to signal that the 
first instruction of the code body is native code. 

Finally, since the assembler-generated code 
segments can't know what program or unit they 
are to be linked to, the Prog_Name entry in the 
Seg_Famly array of the segment dictionary should 
be blank-filled, and the Data_Seg_Num field in 
the List_Header record of all Base_Rel relocation 
sublists should be zero-filled. 
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It is the linker's responsibility, when linking 
assembler-generated segments, to convert all 
Proe_Rel relocation sublists into Seg_Rel 
relocation lists, to correctly set the 
Data_Seg_Num field in the ListJHeader of all 
Base_Rel relocation sublists, and to collect all 
relocation sublists and place them after the 
procedure dictionary of the code segment. The 
linker should also update the Relocatable bit in 
the Seg_Misc array, depending on the information 
supplied in linker information. 
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THE P-MACHINE 



The P-Maehine 



OVERVIEW 

The p-machine is an idealized machine. Compiled 
user programs, system programs such as the filer, 
and the operating system itself run on the 
p-machine. Code for the p-machine is known as 
p-code, and all code files in the system consist of 
either p-code or native code (that is, code for a 
particular physical processor). 

P-code is designed to be compact, so that programs 
in p-code are much shorter than equivalent 
programs in native code. P-code is also designed 
to be easily generated by a compiler. 

Because p-code is compact and simple, relative to 
native codes, it's fairly easy to implement the 
p-machine on a variety of actual processors. It is 
also easier (and cheaper) to maintain a system that 
runs on one p-machine, rather than a family of 
systems, each dedicated to a particular physical 
processor. This is the key to the portability of the 
p-System. 
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Emulative Execution 



The "p" in "p-code" and "p-maehine" stands for 
"pseudo." The p-machine emulator program is 
written in the native code of a particular 
processor. It is responsible for executing p-code 
instructions and controlling machine-dependent 
I/O. The p-machine emulator is also called the 
PME (or the interpreter). 

At run-time, the user's program (or a portion of 
it) is in main memory. The PME fetches each 
p-code instruction, in sequence, and performs the 
appropriate action. 

The process of bootstrapping involves loading the 
PME (if necessary) and starting its execution. 
(The next step is to call the operating system, 
which runs on the p-machine). 



The Stack and the Hea n 

The system maintains data in two dynamic 
structures called the stack and the heap. The 
stack is used for static variables, bookkeeping 
information about procedure and function calls, 
and evaluation of expressions. The heap is used 
for dynamic variables, including the structures 
that describe a program's environment. It is also 
used to store private stacks for subsidiary 
processes and to store code segments that are 
position-locked. 
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The stack is an integral part of the p-machine 
architecture. Most p-code instructions affect the 
stack in one way or another. 

The heap is an integral part of the system, but 
is primarily supported by the operating system, 
rather than the p-machine. 

Both the stack and the heap reside in main 
memory, and grow toward each other in a 
(largely) first-in-first-out manner. Between them 
is an area of memory that is partly unused, but 
may contain the code pool (see below). 

The heap is more fully described in Chapter 5, 

"The Operating System." 



Code Segments 

In the p-System, program code is stored in one or 
more segments. A code segment may contain 
either p-code or native code (or both). Besides 
the code itself, each code segment contains 
bookkeeping information for the system's use, and 
(usually) a pool of constants. 

Every "compilation unit" (a separately compiled 
Pascal PROGRAM or UNIT) results in a "principal 
segment" of code. In addition, there may be 
"subsidiary segments," if the program or unit 
contains SEGMENT routines. Information 

embedded in the compilation's code file contains 
the references among the (possibly) various 
compilation units that are part of the full 
program. 
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When a program is X(ecuted, the operating system 
reads this reference information and resolves the 
references by finding the location of all 
compilation units needed by the program 
(including subsidiary segments and indirect 
references, such as a UNIT using another UNIT). 
Tables are built that may be used at run-time to 
make references (such as procedure calls) from 
one segment to another. 

The segments of a running program compete for 
space in main memory with each other. If the 
code pool is internal (between the stack and 
heap), then the segments also compete with the 
stack and the heap. The principal constraint (as 
far as code segments are concerned) is that both 
the calling and called segment must be present in 
main memory for an intersegment call to succeed. 

Segments in main memory are stored contiguously 
in an area called the code pool. On nonextended 
memory systems, the code pool resides between 
the staek and the heap (an internal code pool). 
On extended memory systems, the code pool 
resides outside of the stack/heap area (an 
external code pool). The code segments may be 
moved about within the code pool or discarded in 
order to create more room. 

Code segments are described in this chapter. 
Code pool handling is described in Chapter 5, 
"The Operating System." 
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Device I/O 

Device I/O and control is accomplished by calls 
from the language level to routines within the 
PME. The device I/O routines then. call on the 
routines of the PME's BIOS (for Basic I/O 
Subsystem), and the BIOS routines control the 
peripheral hardware directly. I/O environment 
dependencies are, thus, isolated in the BIOS, and 
it is possible to adapt the p-System to a new 
hardware environment by changing only the BIOS 
(not the entire PME). 

On adaptable systems, the BIOS itself has a 
standard interface to the SBIOS, or Simplified 
BIOS . The SBIOS is a set of simple I/O routines, 
and is intended to allow the user to rapidly 
adapt the system to a new I/O environment. 

The BIOS is dealt with in Chapter 4, "Low-Level 
I/O." The SBIOS is described in the Adaptable 
System Installation Manual . 
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CODE SEGMENT ENVIRONMENTS 



Segment Information Blocks (SIBs) 

A Segment Information Block (SIB) is a record 
that contains information about an "active" code 
segment. A code segment is active if it may be 
used by a program that is running. A SIB is 
allocated on the heap, and remains there as long 
as the segment is active. There is only one SIB 
for each code segment, no matter how many 
other segments may be using it. 

A code segment need not be in memory to be 
active; an active code segment may be on disk or 
in the code pool, but its SIB will always be on 
the heap. One exception to this is that some 
operating system segments may be allocated 
outside of the stack/heap space by the bootstrap. 
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The following fragment of Pascal code describes 
a SIB: 



RECORD 

Seg_Pool: Pool_Ptr; {points to the description of the code pool 

where the segment resides} 
SegJBase: Kem_Ptr; {byte offset within code pool of segment's 

memory location} 
Seg_Refs: integer; It of active calls to the seg) 
Time_Stamp: integer; {memory swap activity} 
Link_Count: integer; {number of links to the SIB} 
Residency: -1. .maxint ; {-1 - pos lock, - swap, n = mem lock) 
Seg_Name: PACKED ARRAY [0..7] OF CHAR; 
Seg_Leng: integer; {♦ of words in segment} 
Seg_Addr: integer; {disk address of segment} 
Vol_info: VIP; {pointer to disk drive info} 
Data_Size: integer; {number of words in data segment} 
Res_SlBs: RECORD {code pool management record) 
Next_SIB, {next SIB in list) 
Prev_aiB: SIB_P; {previous SIB in list} 
CASE boolean OF {scratch area} 

TRUE: (Next_Sort: SIB_P) ; {next SIB in sort list} 
FALSE: (New_Loc: Hem_Ptr); {temporary address) 
END {of Res_SIBs}; 
H_Type: integer; 
3 {of SIB} ; 



Seg_Pool points to the description of the code 
pool where the segment resides. If the segment 
is on the heap (or if there is no external code 
pool), this value is set to NIL. (A Pool_Ptr is 
declared as a "PoolJDes.) 

Seg_Base contains the byte offset within the 
code pool of the code segment. If there is no 
external code pool, Seg_Base contains the address 
of the segment within the stack/heap area. If 
the code segment isn't in memory, Seg_Base 
contains NIL. 
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Seg_Refs contains the number of outstanding calls 
to the segment. It is incremented whenever a 
routine outside the segment executes an external 
call to a routine within the segment. It is 
decremented whenever a routine within the 
segment returns to a routine outside the segment. 

Time_Stamp contains a value which is used by 
the operating system to determine which 
segment(s) should be removed from the code pool 
when more space is required. The Time_Stamp 
field indicates which segment is least recently 
used. The SYSCOM area, within the operating 
system's KERNEL, contains a 16-bit variable 
which is incremented every time a segment is 
exited. This value is placed into the Time_Stamp 
field of the SIB for the segment being exited. 

Link_Count contains the number of links to the 
SIB from other operating system data structures. 
When Link_Count becomes zero, the SIB is 
removed from the heap (the space it occupied is 
available again). 
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Residency contains a value between -1 and 
maxint, A -1 indicates that the segment is 
position-locked (this occurs when the Boolean 
Relocatable in the segment dictionary is FALSE). 
A zero indicates that the segment is wwappable 
(that is, it can be removed from memory if 
necessary). A value greater than zero indicates 
that the segment is memory-locked. In this case, 
the value is a count of the number of memory 
lock operations that have been applied to that 
segment. Residency is incremented when a 

program declares the segment to be 
memory-locked, and decremented when a program 
declares it to be swappable. It becomes actually 
swappable when residency is equal to zero (that 
is, when no outstanding memory-lock operations 
remain). Programs can control the residency of 
segments bv usine the intrinsics MEMLOCK and 
MEMSWAP. 



Seg_Name contains the first eight characters of 
the segment's name. 



SegJLeng contains the number of words that the 
code segment occupies (including any relocation 
lists, but excluding segment reference lists). 

Seg_Addr contains the segment's first block 
number on disk. 



Vol_Info contains a pointer to a volume 

information record that contains the drive number 

and volume name of the disk on which the 
segment is resident. 
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Data_Size contains the number of words in the 
code segment's data segment. This only applies 
to principal segments; otherwise, Data_Size should 
be zero. 

Res_SIBs is used to maintain the code pool. All 
SIBs of segments in the code pool are on a 
doubly-linked list formed by the Prev_SIB and 
Next_SIB pointers. The Sort_SIB and New_Loc 
fields are used for temporary values while 
managing the code pool. 

The operating system uses several data structures 
to manage code segments by maintaining active 
SIBs and managing the code pool. All of these 
data structures refer to SIBs through pointers. 

When a program being prepared for execution 
requires a code segment that isn't yet active, the 
appropriate SIB is allocated on the heap and 
initialized. The operating system creates a 

ri ointer to the SIB and the SIB's Link Count is 
incremented. When the segment is no longer 
needed, the pointer is removed, and the 
Link_Count is decremented. When Link_Count 
becomes zero, the SIB is removed from the heap. 
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Environment Records (ERecs) 

A code segment's "environment" is a mapping of 
segments it may access to local segment numbers. 
Segment numbers have local meaning; a segment 
may refer only to segments that have been 
assigned local segment numbers— not to segments 
outside its scope. 

For each segment, there is an Environment 
Reco rd (E_Rec). This record designates an 

Environment Vecto r (E_Vect) that describes the 
mapping of local segment numbers to actual code 
segments. 

The following fragment of pseudo-Pascal describes 
environment records and vectors: 



E_Vect_P = E_Vect; 
E_Rec_P = *E_Rec ; 

E_Vect = RECORD 

Vec_Length: integer; {number of local segments) 
Hap: ARRAY [1 . -Vec_Length] OF E_Rec_P; 

{local environment mapping} 
END {of E_VeCt); 

E_Rec = RECORD 

Env_Data: Mem_Ptr; {pointer to global data) 
Env_Vect: E_Vect_P; {pointer to environment} 
Env_SIBs SIB_P; {pointer to SIB for seg number} 
CASE boolean OF 

TRUE : (Link_Count: integer; {number of links to E_Rec) 
Nextjtec: E_Rec_P) ; {next environment record} 
END {of E_Rec) ; 



Env_Data points to the segment's global data. 
(The data is allocated on the heap when the 
program is executed.) 
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Env_Vect is an array of pointers to E_Rec's. It 
is indexed by a segment number— the pointer 
indicates an E_Ree that describes a code 
segment. In this way, a mapping from local 
segment numbers to actual segments is 
accomplished. 

Env_SIB points to the segment's SIB. (It is also 
placed on the heap when the program is called.) 

Link_Count indicates the number of active 
compilation units that are currently USEing the 
segment. This only applies to the principal 
E_Rec of a compilation unit. Link_Count is 
maintained in the same way a SIB's Link_Count is 
maintained. 

Next_Rec is a pointer on a chain of all active 
compilation units. This chain is called UnitJList. 
This field also applies only to the principal 
E_Rec's of a compilation unit. 

In order to minimize index manipulations, the Map 
array in an E_Vect record starts at 1. Thus, it 
may be indexed by local segment numbers (these 
must be 1 or greater). The VecJLength field of 
the record may be considered to occupy the 
zero'th position of the map. 
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The operating system uses a recursive routine to 
construct the environments of a program's USEed 
units, and then its subsidiary segments and 
principal segment (its "native segments"). The 
algorithm is roughly: 



FUNCTION Build_Env CSeg_Dict): E_Rec_P; 
BEGIN 

IF outer block segment E_Reo exists in Dnit_List 
THEN 
BEGIN 

increment Link_Count; 
return existing E_Rec_P 
END 
ELSE 
BEGIN 
create E_Vect; 

create Env_Data for .outer block data space; 
IF there are USEd units indicated in Seg_Dict THEN 
FOR all USEed units DO 

install Build_Env (New_Seg_Dict) into current E_Vect ; 
FOR all native segments DO 
BEGIN 

create E_Rec and SIB for native segment; 
install E_Vect, SIB, and Env_Data in E_Roc; 
install E_Rec for native segments in E_Vect 
END; 

install E_Rec for outer block segment on Unit_List; 
return E_RecJ for outer block segment 
END 
END 



function returns a pointer to the 
E_Rec for the outer block of the program being 
executed. This pointer is installed into the 
operating system's User_Program E_Vect entry. 
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After a program's execution, a recursive routine 
is used to delink the environment for the 
program's outer block and all subsidiary units and 
segments. The algorithm is roughly: 



PROCEDURE Dump_Env (E_Rec_P) ; 
BEGIN 

decrement Link_Count; 
IF Link_Count = THEN 
BEGIN 

de_link from Unit_List; 
DISPOSE (Env_Data) ; 
FOR all E_Rec's on E_Vect whose 
Seg_Vect <> E_Rec .Seg_Vect DO 
Dump_Env (those E_Rec's); 
FOR all E_Rec's on E_Vect whose 

Seg_Vect = E_Rec.Sec_Vect DO 
BEGIN 

de_link E_REC" .SEG_SIB; 
DISPOSE (those E_RECs) ; 
END; 

DISPOSE (E_Rec.Seg_Vect) ; 
END 
END 



The operating system sets its E_Vect entry for 
the terminating program to NIL, and calls 
Dump_Env for the outer block's E_Rec. After 
Dump_Env returns, a pass is made through the 
Res_SIBs list to find all segments whose 
Link Count = 1, and remove them from the heap. 
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TASK ENVIRONMENTS 

A task is a routine that is executed concurrently 
with other routines. A task is implemented by 
three data structures: the body, the Task 
Information Bloek (TIB), and the task queue. In 
Pascal, a task is known as a PROCESS. 

The "main task" of the p-System is the thread of 
execution that runs from operating system 
initialization and all system utility or user program 
executions to the termination of the operating 
system. A program may have subsidiary tasks. 

During execution, each subsidiary task uses its own 
stack instead of the system stack. The task's 
activation record (described later in this chapter) is 
actually contained in the task stack; both are 
allocated on the heap, along with an amount of 
free space into which the stack may grow. 

The task body is a portion of a p-code segment. 
In structure, it's no different from the body of a 

The amount of space allocated to the task stack 
depends on the Stack_Size parameter of the START 
intrinsic. The default is 200 words. 

The main task uses the system stack for expression 
evaluation and activation records. The heap is 
shared by the main task and all subsidiary tasks. 
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The TIB of a subsidiary task is allocated on the 
heap when the task is started. It contains 
information about a task's execution environment. 
This must be maintained, and restored whenever a 
task is restarted after having been idle. 

At any given time, the p-machine may have: 

one task running; 

several tasks ready to run; and 

several tasks waiting for semaphores. 

The tasks that are ready to run are organized into 
a queue. There is also a queue of tasks waiting 
for each semaphore (the queue may be empty). 
Tasks in queues are ordered by their priority. 

The p-machine register CURTSK always points to 
the TIB of the currently executing task. The 
register READYQ points to the first in the list of 
tasks ready to run. 
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The following fragment of Pascal code describes 
TIB: 



TIB = RECORD {Task Information Block) 
Regs: PACKED RECORD 

Kait_Q: TIB_Ptr; 

Prior: byte; 

Flags: byte; 

SP_Low: Hem_Ptr; 

SPJpr: Mem_Ptr; 

SP: Mem_Ptr; 

MP: MSCW_Ptr; 

Reserved: Integer 

IPC: integer; 

Env: ERec_Ptr; 

Proc_Nuin: byte; 

TI_BIOResult: byte; 

Hang_Ptr: Sem_Ptr; 

M_Depend: integer; 
END (of Regs) 
Main_Task: Boolean; 
Start_MSCW: MSCW_Ptr; 
END {of TIB) 



SP is the p-machine stack pointer. SP_Low and 
SP_Upr are the lower and upper bounds for this 
task. 



MP designates the local activation record for this 
task. 



IPC is the p-code instruction counter (a segment 
relative byte pointer), and Proc_Num is the number 
of the executing routine. 

Priority contains the task's priority. This is a 
number from through 255. The higher the value, 
the greater the priority. 

Wait_Q is used when the task is waiting to run, or 
waiting for a semaphore. Wait_Q is one link in a 
linked list of TIBs. 
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When a task is waiting for a semaphore, Hang_Ptr 
points to that semaphore. If the task isn't waiting 
for a semaphore, Hang_Ptr is NIL. Hang_Ptr 
allows a task to be removed from a semaphore's 
wait queue if the task is being terminated. 

Flags are reserved for future use. 

Env is a pointer to the task's current E_Rec. The 
task's current SIB may be found through the E_Rec. 

TIBIO_Result is used to save an IORESULT that is 
local to the task. 

M_Depend contains machine-dependent data 
maintained by the PME. It is initialized to 0. 

MainJTask, if TRUE, indicates that this is the TIB 
of a "root" ("parent") task. 

Start_MSCW points to the MSCW (mark stack 
control word) of the routine that STARTed this 
task. 

Further information about tasks appears below in 
Chapter 5, "The Operating System." Figure 3-1 
shows the layout of main memory while the system 
is running, including the location of task stacks as 
discussed in this section. 
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INTERPRETER 



MAIN MEMORY USAGE 
(Non-Extended Memory) 

Figure 3-1. Main Memory Usuage 
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P-MACHINE INSTRUCTIONS 

The Intrinsic P_MACHINE 

A Pascal compilation unit may directly generate 
in-line p-code. This is done by calling the 
intrinsic procedure P_MACHINE. Producing 

in-line p-code may be useful in very low-level 
system programming. Absolutely no protection 
is provided by this intrinsic or the system; it can 
only be used at the user's risk, and extreme 
caution should be exercised. 



The form of a call to PJMACHINE may be 
sketched as follows: 



PJ1ACHINE ( <p-machine item> {, <p-machine item>} ) 

that is, the parameters to the procedure are a 
list of one or more <p-machine item>s. A 
<p-machine item> describes a portion of p-code, 
and causes one or more bytes to be generated. 

There are three varieties of <p-machine item>: 

1. P-code syllable: The simplest item is a 
(non-real) scalar constant. This item produces 
a single byte of p-code, which is the least 
significant byte of the specified constant. 
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2. Expression value: If the item is an expression 
enclosed in parentheses, then a p-eode 
sequence is generated which will compute the 
value of the expression and leave it on the 
stack. 

3. Address reference: If the first token of the 
item is '"*, then the item is the specification 
of a variable, and p-code is generated which 
leaves the address of that variable on the 
stack. 



A <p-machine item> may not be a string 
constant. 
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EXAMPLE: 

Given these declarations: 

CONST STO = 196; 



TYPE Records = RECORD 

First_Field, Second_Field: integer 
END; 
PJecords = "Records; 

VAR Vector: ARRAY [0..9] OF PJiecord; 
i: integer; 



... the following call to P_MACHINE ... 

P_MACHIKE ( "Vector [5]". First_Field, <i*i), STO) 

would cause the square of "i" to be stored in the 
first field of the record designated by the sixth 
element of the array Vector. 
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P-MACHINE REGISTERS 

Like other processors, the p-maehine has registers 
which are a fundamental part of its architecture. 
Since the p-machine is usually emulated by a 
program on a host processor, these registers may or 
may not correspond to actual host processor 
registers. 

Unlike most processors, the p-machine doesn't allow 
its registers to be used in a general fashion. All 
registers have specific uses. The p-machine stack 
takes the place of general purpose registers; all 
temporary data is stored there. 

Here is a list of the p-machine registers, along 
with a description of how they are used. All the 
registers listed below are required registers that 
will be found on each p-machine. They are the 
registers that may be accessed via the LPR (Load 
Processor Register) and SPR (Store Processor 
Register) instructions. Some p-machines may have 
additional registers for optimization. These will be 
mentioned below where appropriate. 



CURPROC 

The CURPROC register contains the procedure 
number of the currently executing procedure. It 
changes whenever a procedure call is made. 
There is a maximum of 255 procedures per 
segment, so CURPROC will have a value in the 
range 1 through 255. 
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CURTASK 



The CURTASK register is a pointer to the TIB 
of the currently executing task. It changes 
whenever a task switch occurs. 



EREC 

The EREC register is a pointer to the E_Rec 
(Environment Record) of the current environment. 
It changes whenever a call or return is made to 
a procedure in a different segment. The E_Rec 
contains pointers to the global data, EVEC and 
SIB. Often the pointer to the global data is 
kept as a register called BASE. Also, a pointer 
to the SIB may be kept as a register called SIB, 
and the location in memory of the current 
segment (found in the SIB) may be kept as a 
register called CURSEG. If BASE, SIB, or 
CURSEG are kept as auxiliary p-machine 
registers, they must be updated whenever EREC 
is changed. 



EVEC 

The EVEC register is a pointer to the E_Vect 
(Environment Vector) of the current environment. 
It changes whenever a call or return is made to 
a procedure in a different segment. The EVEC 
is a redundant register, because the E_Vect may 
be found through the EREC register. The EVEC 
register is used to find the E_Rec of a different 
segment in order to access its data or to call a 
procedure in that segment. 
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IORESULT 

IORESULT contains the code resulting from the 
last I/O operation. This is the only register that 
may be accessed directly (without a Load 
Processor Register instruction) by the operating 
system since it is located in SYSCOM. 
IORESULT changes whenever it is modified by 
the operating system, or whenever an I/O 
operation occurs. IORESULT is limited in size to 
the range through 255. 



IPC 



The IPC register is a pointer to the next p-code 
that will be executed relative to the currently 
executing segment. It changes during each 

p-code execution. 



MP 



The MP register points to the current activation 
record (MSCW). It changes whenever a procedure 
call or return is made. All variables (except 
those that have been dynamically allocated on 
the heap) are accessed from an MSCW. Local 
variables are accessed from MP, global variables 
from BASE (see EREC, above), and intermediate 
variables from an intermediate MSCW. 
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READYQ 



The READYQ register points to the TIB at the 
head of the queue of tasks ready to be run. It 
may change on a SIGNAL or WAIT p-code, or 
when an attached semaphore is signalled. 



SP 



The SP register points to the word that is on the 
top of the p-maehine stack. It changes on nearly 
every p-code, whenever an item is pushed on or 
popped off the stack. 
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FAULTS 

A fault is a special condition recognized by the 
PME during execution of a p-eode that requires 
operating system assistance to fix. After handling 
the problem, the operating system returns to p-code 
execution where the fault was detected. The 
p-code where the fault was detected is reexecuted. 

Two types of faults may be issued by the PME: 
segment faults and stack faults. A segment fault 
is issued when a segment that must be accessed 
isn't in memory. A stack fault is issued if there 
isn't enough room on the stack for a p-code to 
perform its operation. Stack height checking is 
done only on p-codes that will place multiple words 
on the stack, except in the case of real number 
operations, which do no stack checking. 

When the fault is detected, the p-machine must be 
returned to the state it was in prior to execution 
of the p-code. This is so that the p-code may be 
reexecuted on return from the fault. 

The fault is issued by saving information in 
SYSCOM, then signalling the semaphore Real_Sem in 
SYSCOM. This signal starts the high priority task 
Fault_Handler in the KERNEL, which processes the 
fault. 
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The following fields in SYSCOM with the indicated 
byte offsets are used in handling faults: 



14 Real_Sem semaphore to start the faulthandler 

18 Fault_TIB TIB of faulting task 

20 Fault_EREC E_EEC of segment to read 

22 Fault_Words number of words needed on stack 

24 Fault_Type 80H=segment fault, 81H=stack fault 



A stack fault sets Fault_EREC to the current 
p-machine EREC. A segment fault sets 

Fault_Words to zero. All other parameters are set 
up as described above. 

The following p-codes may issue a segment fault: 

CAP, CSP, CXL, SCXGn, CXG, CXI, CFP, 
RPU, SIGNAL (if a task switch occurs), WAIT 
(if a task switch occurs) 

The following p-codes may issue a stack fault: 

LDC, LDM, ADJ, SRS, CLP, CGP, SCIPn, CIP, 
CXL, SCXGn, CXG, CXI, CFP 
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EXECUTION ERRORS 

An execution error is a special error condition that 
may be recognized during execution of a p-code. 
When an execution error is detected, the PME calls 
the operating system routine Exec_Error to report 
the error. On the call, no stack checking should 
be done in order to prevent a stack fault. 

Under normal circumstances, Exec_Error won't 
return and continue p-code execution where the 
execution error was detected. Instead, the system 
will be reinitialized. However, it is possible for 
you to specify that execution should continue. 
Thus it is highly desirable that each p-code that 
can cause an execution error leave the p-machine 
in a consistent state on detection of the error. 
Usually it is best to leave IPC pointing to the next 
p-code, putting "dummy" results on the stack; that 
way the p-code won't be reexecuted on return. 
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The call to Exec_Error is made by performing a 
CXG 1,2 (an external call to KERNEL, procedure 
2) with the stack as follows: 

Stack: 



MSCW 



<- SP 



17777777777771 ^sp 
before 



data 



int 







777777777777 
after 



TOS and TOS-1 are the usual elements placed on 
the stack for a procedure call. TOS- 2 is the 
execution error number. TOS-3 and TOS-4 are 
dummy parameters. (TOS indicates the element at 
the top of the stack. TOS-1 indicates the second 
element from the top, and so forth.) 
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Below is a list of the execution errors, along with 

the execution error number, the p-codes that may 

issue the error and a description of what the error 
means. 



Value Range Error 

Number: 1 

P-Codes: CHK, CSTR 

Description: 

A value range error is issued if an array index or 
scalar is out of bounds. This is detected only with 
one of the special check instructions. 
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No Proc in Seg Table 

Number: 2 

P-Codes: CLP, CGP, SCIPn, CIP, CXL, 

SCXGn, CXG, CXI, CFP 

Description: 

A no-pro c-in-seg-table error is issued whenever a 
call is made to a procedure whose procedure 
dictionary entry is zero. This condition indicates 
that the procedure hasn't been linked into the host 
program. 

Integer Overflow 
Number: 5 

P-Codes: <long integer routines> 

Description: 

An integer overflow error is issued on a conversion 
from long integer to integer, where the resulting 
integer is too large to fit into 16-bits. It will also 
be generated if a long integer on the stack is too 
large to be stored. 
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Divide by Zero 

Number: 6 

P-Codes: DVI, MODI, DVR, <long integer 

routines> 

Description: 

A divide-by-zero error is issued whenever division 
or the remainder function is attempted with a zero 
denominator. 



Program Interrupted by User 

Number: 8 

P-Codes: <none> 

Description: 

A program-interrupted-by-user error is issued 
whenever the BIOS informs the PME that the break 
key has been pressed and break hasn't been 

*3! LI 3 

U-LSctUIt^U. 
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I/O Error 

Number: 10 

P-Codes: <IOCHECK> 

Description: 

An I/O error is issued on the IOCHECK standard 
procedure when IORESULT is nonzero. 

Unimplemented Instruction 
Number: 11 

P-Codes: <any unimplemented p-code> 

Description: 

An unimplemented-instruction error is issued if an 
attempt is made to execute an illegal or reserved 
p-eode. 
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Floating Point Error 

Number: 12 

P-Codes: LDCRL, LDRL, STRL, FLT, TNC, 

RND, ABR, NGR, ADR, SBR, MPR, 
DVR, EQREAL, LEREAL, GEREAL, 
<POWEROFTEN> 

Description: 

A floating point error is issued if the result of a 
floating point calculation isn't a legal floating point 
number. This may happen on floating point 

overflow. This error is also issued if a floating 
point p-code is executed with a PME that doesn't 
support floating point. 
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String Overflow 
Number: 13 

P-Codes: CSP, ASTR, <long integer routines> 

Description: 

A string overflow error is issued on string 
assignment to a string that is too small to hold the 
source string. 

Break Point 

Number: 16 

P-Codes: BPT 

Description: 

A break point error is issued when a break point 
p-code is executed. This error will result in 
entering the Debugger if the Debugger is currently 
running. 
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Set Too Large 

Number: 18 

P-Codes: SRS 

Description: 

A set-too-large error is issued if an attempt is 
made to create a set that is larger than the 
largest allowed set size. 

Segment Too Large 

Number: 19 

P-Codes: <READSEG> 

Description: 

A segment-too-large error is issued if an attempt is 
made to read, with the standard procedure 
READSEG, a segment that is too large. This 
execution error is generated only by p-machines 
that have an unusual restriction on segment size. 
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P-CODE INSTRUCTIONS 

Instructions for the p-machine consist of an opcode, 
which is one or two bytes long, followed by zero 
to three parameters. There are 217 p-code 

instructions (255 minus 38 currently unused 
instructions). P-machine instructions are described 
at the end of this section. They are also listed 
alphabetically in Appendix A and numerically in 
Appendix B. 

Here is a description of a typical p-code 
instruction. (The format of the description is the 
same for all p-eodes.) 



3-40 0400101:03A 



The P-Maehine 



LDCB 


Load Constant Byte 


Opcode: 


128 


80 


Operation: 


LDCB 


UB 


Stack: 


\<r SP 






UB 


VUIIIIIIIII 


VIUIIIIIUI 


before 




after 


Description: 







<r SP 



The constant UB with high byte zero is pushed 
onto the stack. LDCB is used to load a constant 
in the range through 255. 

The top line shows the mnemonic of the p-code 
(LCDB) and its name (Load Constant Byte); the 
second line shows its value, both decimal (128) and 
hexadecimal (80). 



The third line defines the operation of the 
instruction. The mnemonic is followed by the 
instruction's parameter— more specifically, the 
format of the instruction's parameter. Here the 
format is UB, meaning unsigned byte. UB and the 
four other paramter formats are discussed below. 

NOTE: Most p-machine instructions don't have 
specific parameters but instead deal with operands 
that are on the stack. 
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The s tack part of the description shows the 
contents of the stack before and after execution of 
the instruction. SP means stack pointer; it points 
to the top of the stack (TOS). 



Instruction Parameters 

The parameters to a p-code instruction contain 
information about the size and number of the 
instruction's operands. (In some cases, the 

parameter may be an operand itself, as in the 
case of LDCB, shown above.) 

The five parameter formats are: 

1. UB — Unsigned Byte 

Represents a positive integer in the range 
through 255. When eonvereted to a 16-bit 
value, the most significant byte is zeroed. 

2. SB — Signed Byte 

Represents a tv/o's complement 8-bit integer in 
the range -128 through 127. When converted 
to a 16-bit two's complement value, the most 
significant byte is a sign extension (all bits 
equal bit 7 of the low byte (SB)). 

3. DB - Don't Care Byte 

Represents a positive integer in the range 
through 127. Bit 7 is always 0. When 
converted to a 16-bit value, the most 
significant byte is zeroed. 
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4. B — Big 

This is a parameter with variable length. If 
bit 7 of the first byte is 0, the remaining 7 
bits represent a positive integer in the range 
through 127. If bit 7 of the first byte is 1, 
then bit 7 is cleared; the first byte is the 
high-order byte of a 16-bit word, and the 
following byte is the low-order byte of that 
word. The big format may represent positive 
integers in the range through 32767. 

5. W - Word 

This is a 2-byte paramter. It is a 16-bit 
two's complement value that represents an 
integer in the range -32768 through 32767. 
The word is always represented as 
least-significant-byte in the code stream. 



Dynamic Operands 

This section describes the stack-oriented dynamic 
operands of p-machine instructions. 

Activation Record 

An activation record is created for each 
invocation of an active routine. Figure 3-2 
illustrates an activation record. 
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Addr (address 

A 16-bit p-machine pointer. It may be a byte 
address, in which case it is restricted to even 
values. On word-addressed processors, a pointer 
may be a word address. 

Bool (boolean) 

A 16-bit quantity treated as a logical value. If 
bit 15 is 0, the value is FALSE. If bit 15 is 1, 
the value is TRUE. 

Byte-ptr (byte pointer) 

A 32-bit quantity. TOS is an index into an array 
of bytes. TOS-1 is the word address of the base 
of the byte array. Two words are used in a 
byte-ptr so that individual bytes may be specified 
on word-addressed processors. 

Int (integer) 

A 16-bit two's complement integer. 

Nil 

A constant that references an i nvalid address. 
The actual value varies from 
processor-to-processor. (See the p-code 

description of LDCN for a table of NIL values 
for various processors.) 
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Offset 

An offset into a code segment. This is either a 
word or a byte offset, depending on the natural 
addressing unit of the host processor. 

Pack-ptr (packed array pointer) 

Three words that designate a bit field within a 
16-bit word. TOS is the number of the rightmost 
bit of the field, TOS-1 is the number of bits in 
the field, and TOS-2 is the address of the word. 

Real 

A 32-bit or 64-bit floating point quantity. 
Set 



A set is through 255 words of bit flags, 
preceded by a word that contains the number of 

wnrris in thp spt. 



Word 

A 16-bit quantity that may be treated in any 
way— as an integer, boolean, address, and so 
forth. 
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Word-block 

A group of Zero or more words. 
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Activation Records 



An activation record is created for each 
invocation of an active routine. Figure 3-2 
illustrates an activation record. 



( 



Mark, 
Stack 



high address 



function value 



parameters 



locals 

and 

temporaries 



MSPROC 



MSIPC 



MSDYN 



MSSTAT 



OATASIZE 
words 



least significant 
J byte 



low address 

Figure 3-2. Procedure Activation Record 
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The parts of an activation record are: 

1. Mark stack. This area contains five (full) words 
of housekeeping information: 

a. MSSTAT — pointer to the activation record of 
the lexical parent. 

b. MSDYN — point to the activation record of 
the caller. 

c. MSIPC — segment relative byte pointer to 
point of call in the caller. 

d. MSENV — E_Ree pointer of the caller. 

e. MSPROC — procedure number of caller. 

2. Local and temporary variables. This area is 
Data_Size words long. 

3. Parameters. This area (which may be empty) 
contains: 

a. Addresses — for VAR parameters, and record 
and array value parameters. 

b. Values — for other value parameters. 

4. Function value. This area is present only for 
functions, and is either one or two words (or 
four words, if reals are that size). 
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P-CODE DESCRIPTIONS 



ABI 


Absolute 


Value Integer 


Opcode: 


224 


EO 


Operation: 


ABI 




Stack: 


<r SP 




int 


int 


VlllUiWU 
before 


\iimiimii 

after 


Description: 







<r SP 



TOS is replaced by the absolute value of TOS. If 
TOS was initially -32768 the result should be 
-32768. 
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ABR 


Absolute Value Real 


Opcode: 


227 


E3 


Operation: 


ABR 




Stack: 


<r SP 




1 1 
: real : 


1 \<r SP 

: real : 


before 




\miumiii 1 

after 



Description: 

TOS is replaced by the absolute value of TOS. 
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ADI 


Add 


Integers 


Opcode: 


162 


A2 


Operation: 


ADI 




Stack: 


<r SP 




int 








int 




int 


<- SP 


VUIJUIIlfl 
before 


vuumnii 

after 




Description: 











TOS is replaced by TOS-1 + TOS. The result 
should be computed as if it were an unsigned 
operation on 32-bit operands, and only the lowest 
16 bits were retained for the result. Thus, 

overflow or underflow will "wrap around" to the 
opposite sign. 
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ADJ 
Opcode: 
Operation: 
Stack: 



Adjust Set 

199 

ADJ 



C7 
UB 



: set 

YnmmTTT 

before 
Description: 



l<r SP 



: word-blk 

VfTTTTTTTTTT 
after 



T<- SP 



If less than 20 words on the stack will be available 
after the completion of the adjust, a stack fault is 
issued. 



The set TOS is stripped of its length word and 
then expanded or compressed so that it is UB 
words in size. Ex n ansion is done b u adding words 
of zeros "between" TOS and TOS-1. Compression is 
done by removing high words of the set. It is 
legal for adjust to remove "significant" words of 
the set during compression. 
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ADR 


Add 


Real 




Opcode: 


192 




CO 


Operation: 


ADR 






Stack: 


\<r SP 

■ 
• 






1 

: real ; 

1 




1 

: real : 


r 


\<r SP 
real : 


vmuiiim 




I////////////I 


before 






after 


Description: 









TOS is replaced by the value TOS-1 + TOS. The 
result should be zero on underflow. A floating 
point execution error is issued on overflow. 
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ASTR 
Opcode: 
Operation: 
Stack: 



Assign String 
235 EB 

ASTR UB1, UB2 



addrlofs 



addr 

1777777777777 
before 

Description: 



<r SP 



[7777777777771 <- sp 
after 



TOS-1 is the address of the destination string 
variable. UB2 is the declared size of that string 
(the number of characters it may hold). TOS is 
either the address of a string variable (if UB1 is 
zero), or the offset of a string constant in the 
constant pool of the current segment. 

A string overflow execution error is issued if the 
dynamic size of the source string is greater than 
the declared size of the destination string. 

Otherwise, the source string is copied to the 
destination string. 
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BNOT 
Opcode: 
Operation: 
Stack: 



Boolean Not 
159 9F 

BNOT 



bool 

1777777777777 
before 

Description: 



<r SP 



bool 

1777777777777 
after 



<- SP 



The one's complement of TOS is masked to one bit, 
and the result is pushed on the stack. BNOT 
produces a 1 (TRUE) or a (FALSE) on the stack, 
regardless of how many bits were set in TOS. 
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BPT 


Break point 


Opcode: 


158 9E 


Operation: 


BPT 


Stack: 





MSCW 



T<- sp 



: data 

1/77777777777" 
after 



17777777777771 <-SP 
before 

Description: 



A break point execution error is issued 
unconditionally. 
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CAP 


Copy Array Parameter 


Opcode: 


171 AB 


Operation: 


CAP B 


Stack: 




addr 


<r SP 


addr 




\lllillllllll 


l////////////l<-SP 


before 


after 


Description: 





TOS is the address of a parameter descriptor for a 
packed array of characters. The parameter 

description is a two word record. The first (low) 
word is either NIL, or a pointer to an E_Rec. If 
the first word is NIL, the second word is the 
address of the paramter. If the first word points 
to an E_Rec, the second word is an offset relative 
to the segment indicated by the E_Rec. This 
offset was created with an LCO instruction. 

A segment fault is issued if the parameter 
descriptor indicates a nonresident segment. 
Otherwise, the array (which is B words big), is 
copied to the destination at address TOS-1. 
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CFP 
Opcode: 
Operation: 
Stack: 



Call Formal Procedure 



151 
CFP 



97 
UB 



proc-num 



erec-p 



<~ SP 



MSCW 



l<r SP 



: data 

1777777777777 
after 



stat-lnk 

vim/nun 

before 
Description: 



TOS contains a procedure number. TOS-1 contains 
an E_Rec pointer, TOS-2 contains a static link. 
The procedure TOS in the segment indicated by 
TOS-1 is called. 

If the segment indicated by TOS-1 isn't in memory, 
a segment fault is issued. 

If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 
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Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to TOS-2. MP is set to point to 
the new MSCW, CURPROC is set to TOS, and IPC 
is set to the first p-code of procedure UB2. 
E_Ree and E_Vect are set to reflect the new 
environment. 

If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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CGP 
Opcode: 
Operation: 
Stack: 



Call Global Procedure 
145 91 

CGP UB 



MSCW 



<r SP 



VT777777T7771 <r SP 
before 

Description: 



: data 

1777777777777 
after 



Global procedure UB in the currently executing 
segment is called. 



if 4~i t^ -. 4- ~ o; j 4?~ — _«. j TTn :_ 

ii inc ljo. t«_oiz.G ivuiu iut yiufcuure \j d io 

negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 



Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the old value of BASE (the 
global data MSCW). MP is set to point to the new 
MSCW, CURPROC is set to UB, and IPC is set to 
the first p-code of procedure UB. 
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If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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CHK 


Check Subrange Bounds 


Opcode: 


203 


CB 


Operation: 


CHK 




Stack: 


<r SP 




int 




int 




int 


int 


ymi/iiiin 

before 


viuiimiii 

after 


Description: 







<- SP 



TOS is an upper-bound. TOS-1 is a lower-bound. 

If it isn't the case that TOS-1 <= TOS-2 <= TOS, a 

value range execution error is issued. TOS-2 
remains on the stack. 
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CIP 

Opcode: 
Operation: 
Stack: 



Call Intermediate Procedure 
146 92 

CIP DB, UB 



77777777777714- sp 
before 

Description: 



MSCW 



<r SP 



: data 

\lllllUIIUI 
after 



Intermediate procedure UB in the currently 
executing segment is called. 

If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made* I 

resumes with the following p-code. 



P-flnrfo ovew»iitir>n 



Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the intermediate MSCW that is 
DB lexical levels above the current MSCW. MP is 
set to point to the new MSCW, CURPROC is set to 
UB, and IPC is set to the first p-code of procedure 
UB. 
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If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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CLP 
Opcode: 
Operation: 
Stack: 



Call Local Procedure 
144 90 

CLP UB 



MSCW 



«- SP 



data 



1777777777777 I^sp 
before 

Description: 



\iuuiiiim 

after 



Local procedure UB in the currently executing 
segment is called. 

If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 

Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The StaticJLink field of 
the MSCW is set to the old value of MP. MP is 
set to point to the new MSCW, CURPROC is set to 
UB, and IPC is set to the first p-code of procedure 
UB. 
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If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 



3-66 0400101:03A 



The P-Machine 



CSP 


Copy 


String Parameter 


Opcode: 


172 


AC 


Operation: 


CSP 


UB 


Stack: 


<r SP 




addr 




addr 




1//////////// 
before 


after 


Description: 







TOS is the address of a parameter descriptor for a 
packed array of characters. The parameter 

description is a two word record. The first (low) 
word is either NIL, or a pointer to an E_Rec. If 
the first word is NIL, the second word is the 
address of the paramter. If the first word points 
to an E_Ree, the second word is an offset relative 
to the segment indicated by the E_Rec. This 
offset was created with an LCO instruction. 
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A segment fault is issued if the parameter 
descriptor indicates a nonresident segment. 
Otherwise, the dynamic length of the designated 
string is compared to UB (the declared size of the 
destination formal parameter). If the string is 
larger than the destination size, a string overflow 
execution error is issued. Otherwise, the string is 
copied to the address TOS-1. 
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CSTR 


Cheek String Index 


Opcode: 


236 


EC 


Operation: 


CSTR 




Stack: 


<r SP 




int 


int 


addr 


addr 


\in/uiiiiu 


\inimiiiu 


before 




after 


Description: 







<r SP 



TOS-1 is the address of a string variable. TOS is 
an index into that variable. 



If the index is less than 1 or greater than the 
dynamic length of the string variable, a value range 
execution error is issued. 
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CXG 


Call 


External Global 


Opcode: 


148 


94 


Operation: 


CXG 


UB1, UB2 


Stack: 


<r SP 






1 1 

: MSCW : 

1 1 




1 1 

: data : 

after 


yiii/mim i 

before 



\<r SP 



Description: 

The global procedure UB2 in segment UB1 is called. 



If segment UB1 isn't in memory, a segment fault is 



issuer], 



If the UB1 is 1 and the procedure number matches 
one of the standard procedure numbers, the p-code 
performs the standard procedure instead of the call. 
See the section describing the standard procedures, 
at the end of this chapter. 
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If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 

Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the new BASE (the global data 
MSCW). MP is set to point to the new MSCW, 
CURPROC is set to UB, and IPC is set to the 
first p-code of procedure UB2. E_Ree and E_Vect 
are set to reflect the new environment. 

If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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CXI 


Can 


External Intermediate 


Opcode: 


149 


95 


Operation: 


CXI 


UB1, DB, UB2 


Stack: 


<r SP 






1 K-s: 

: MSCW : 
1 1 




1 1 

: data : 

viiiu/iiui 1 

after 


before 



Description: 

The global procedure UB2 in segment UB1 is called. 

If segment UB1 isn't in memory, a segment fault is 
issued; 

If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 
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Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The StaticJLink field of 
the MSCW is set to the MSCW, that is, DB lexical 
levels above the current MSCW. MP is set to point 
to the new MSCW, CURPROC is set to UB, and 
IPC is set to the first p-code of procedure UB2. 
E_Rec and E_Vect are set to reflect the new 
environment. 

If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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CXL 


Call 


External Local 


Opcode: 


147 


93 


Operation: 


CXL 


UB1, UB2 


Stack: 


<r SP 






1 1 

: MSCW : 




: data : 


vniiiiui/n 


before 




after 



\<r SP 



Description: 

The local procedure UB2 in segment UB1 is called. 



If segment UB1 isn't in memory, a segment fault is 

issuer). 



If the Data_Size word for procedure UB is 
negative, nothing is allocated on the stack and a 
native code call is made. P-code execution 

resumes with the following p-code. 

Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the old value of MP. MP is 
set to point to the new MSCW, CURPROC is set to 
UB, and IPC is set to the first p-code of procedure 
UB2. E_Rec and E_Vect are set to reflect the 
new environment. 
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If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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DECI 
Opcode: 
Operation: 
Stack: 



int 

777777777777 
before 

Description: 



Decrement Integer 



238 
DECI 



<r SP 



EE 



int 

777777777777 
after 



4- SP 



TOS is decremented by 1. If TOS was initially 
-32768, the result should be 32767. 
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DIF 


Set 


Difference 


Opcode: 


221 


DD 


Operation: 


DIF 




Stack: 


\<r SP 

t 
» 

» 




1 ! 
: set : 




: set : 


1 \<r SP 
: set : 


\nmiuiiir 




\iiimiiiiii i 


before 




after 


Description: 







The difference of sets TOS-1 and TOS is pushed 
onto the stack. The difference is computed as 
bit-wise (TOS-1 AND NOT TOS). 



0400101:03A 



3-77 



The P-Machine 


. 






DUP1 


Duplicate One Word 


Opcode: 


226 E2 


Operation: 


DUP1 


Stack: 










<r SP 


word 


<r SP 


word 


word 




VHIUUUII 


VUIWUIH 




before 


after 


Description: 




The word TOS 


is duplicated on top of the stack 



3-78 



0400101:03A 











The P-Maehine 


DUPR 


Duplicate 


Real 




Opcode: 


198 




C6 




Operation: 


DUPR 








Stack: 


\<r SP 

i 
1 


1 

• 
• 








real 


\<r SP 

• 
• 


1 ! 
: real : 


• 


real 


• 
« 


\mmmm\ 


1 


V 


III mm II 1 


before 






after 




Description: 











The real TOS is duplicated on top of the stack. If 
the p-machine supports 2-word reals, two words are 
duplicated. If the p-machine supports 4-word reals, 
four words are duplicated. If the p-machine 
doesn't support reals, a floating point execution 
error is issued. 



0400101:03A 3-79 



The P-Machine 






DVI 


Divide Integer 


Opcode: 


141 


8D 


Operation: 


DVI 




Stack: 


<r SP 




int 




int 


int 


vimmuii 


Vlilllllllll 


before 




after 


Description: 







<r SP 



If TOS is zero, a divide-by-zero execution error 
occurs. 

Otherwise, TOS is replaced by TOS-1 DIV TOS. 
The division operation is an integer division 
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The P-Machine 


DVR 


Divide 


Real 


Opcode: 


195 


C3 


Operation: 


DVR 




Stack: 


<r SP 




1 1 
: real : 




: real : 


1 \<r SP 
: real : 


\iminum\ 

before 




after 


Description: 







If TOS is zero, a divide-by-zero execution error is 
issued. 



Otherwise, TOS is replaced by the value 
TOS-1 / TOS. The result should be zero on 

underflow. A floating point execution error is 
issued on overflow. 



0400101:03A 3-81 



The P-Machine 




EFJ 


Equal False Jump 


Opcode: 


210 D2 


Operation: 


EFJ SB 


Stack: 




int 


<r SP 


int 




vimiiiim 

before 


l////////////l<-SP 
after 


Description: 





If TOS <> TOS-1, a jump is made, relative to the 
next instruction, by the byte offset SB. 



3-82 



0400101:03A 



The P-Machine 



EQBYT Equal Byte Array 

Opcode: 185 B9 

Operation: UB1, UB2, B 
Stack: 



addr|ofs 



l<r SP 



<r SP 



: addrlofs : 

i i b00 ^ 

17777777777771 777777777777 
before after 

Description: 

UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a byte array (if the corresponding UB is 
zero) or to the offset of the byte array in the 
current segment. B is the size (in bytes) of the 
arrays. 

The boolean result of the comparison TOS-1 = TOS 
is pushed onto the stack. The bytes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the arrays is reached. If there is a mismatch in 
any character position, FALSE is pushed onto the 
stack. Otherwise, TRUE is pushed. 



0400101:03A 3-83 



The P-Maehine 






EQPWR 


Equal Set 


Opcode: 


182 


B6 


Operation: 


EQPWR 




Stack: 


<r SP 




1 1 

: set : 

1 1 




1 1 




: set : 

\miin/ii/i\ 


bool 


ymiimiu 


before 




after 


Description: 







<r SP 



The boolean result of the comparison TOS-1 = TOS 
is pushed onto the stack. The sets need not be 
the same size— only the elements must match. 



3-84 0400101:03A 











The P-Machine 


EQREAL 




Equal 


Real 


Opcode: 




205 


CD 


Operation: 




EQREAL 


Stack: 


\<r SP 

• 
• 

^ 

• 
• 

1 




1 

: real 












: real 

\imiii/mi 

before 




bool 


<r SP 


i 






\iiiiuuim 

after 




Description: 













The boolean result of the comparison TOS-1 = TOS 
is pushed onto the stack. 



0400101:03A 3-85 



The P-Machine 

EQSTR 
Opcode: 
Operation: 
Stack: 



Equal String 
232 E8 

EQSTR UB1, UB2 



addrlofs 



addrlofs 

1777777777777 
before 

Description: 



<r SP 



bool 

1777777777777 
after 



<r SP 



UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a string (if the corresponding UB is zero) 
or to the offset of the string in the current 
segment. 

The boolean result of the comparison TOS-1 = TOS 
is pushed onto the stack. The bytes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the shorter string is reached. The comparison 
begins at the second element of the strings. If 
there is a mismatch in any character position, 
FALSE is pushed on the stack. Otherwise, the 
lengths of the strings are compared, and the 
boolean result of the comparison length(TOS-l) = 
length(TOS) is pushed. 



3-86 



0400101:03A 







The P-Machine 


EQUI 


Equal Integer 


Opcode: 


176 


BO 


Operation: 


EQUI 




Stack: 


<r SP 




int 






int 


bool 


<r SP 


vm/iiiim 


\iniiiiiiui 




before 




after 


Description: 









The boolean result of the comparison TOS-1 = TOS 
is pushed onto the stack. 



0400101:03A 
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The P-Maehine 


■ 




FJP 


False 


Jump 


Opcode: 


212 


D4 


Operation: 


FJP 


SB 


Stack: 


<- SP 




bool 




VIIIIIIIIIII 


1////////////I<-SP 


before 




after 


Description: 







If TOS is FALSE, a jump is made, relative to the 
next instruction, by the byte offset SB. 



3-88 
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The P-Maehine 


FJPL 


False 


Jump Long 


Opcode: 


213 


D5 


Operation: 


FJPL 


W 


Stack: 


<r SP 




bool 




\lllUlllilll 
before 


\////////////\<rSP 
after 


Description: 







If TOS is FALSE, a jump is made, relative to the 
next instruction, by the byte offset W. 



0400101:03A 



3-89 



The P-Machine 


i 


FLT 


Float 


Opcode: 


204 


Operation: 


FLT 


Stack: 




int 


<r SP 


v/iiimiuj 




before 




Description: 





cc 



l<r SP 



: real 

I//////////// 
after 



Integer TOS is converted to a floating point 
number, and the result is pushed onto the stack. 



3-90 



0400101-.03A 



GEBYT 
Opcode: 
Operation: 
Stack: 



The P-Machine 

Greater Than or Equal Byte Array 

187 BB 

GEBYT UB1, UB2, B 



: addrlofs 

: addrlofs 

\ll/IIIIUUI 
before 



\<r SP 



bool 

1777777777777 
after 



<r SP 



Description: 

UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a byte array (if the corresponding UB is 
zero) or to the offset of the byte array in the 
current segment. B is the size (in bytes) of the 
arrays. 

The boolean result of the comparison TOS-1 >= TOS 
is pushed on the stack. The bytes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the arrays is reached. If there is a mismatch and 
the character in TOS-1 < the character in TOS, 
FALSE is pushed onto the stack. Otherwise, TRUE 
is pushed. 



0400101:03A 



3-91 



The P-Machine 

GEPWR 
Opcode: 
Operation: 
Stack: 



set 



Greater Than or Equal Set 
184 B8 

GEPWR 



"[«- SP 



: set 

Vmrmrm 

before 



bool 

1777777777777 
after 



<r SP 



Description: 

TRUE is pushed if TOS-1 is a superset of TOS. 
Otherwise, FALSE is pushed. 



3-92 



0400101:03A 



The P-Machine 



GEQI 


Greater 


Than or Equal Integer 


Opcode: 


179 


B3 


Operation: 


GEQI 




Stack: 


<r SP 




int 






int 


bool 


<r SP 


VillUlflll! 
before 


\iimiimu 

after 




Description: 









The boolean result of the signed comparison 
TOS-1 >= TOS is pushed onto the stack. 



0400101:03A 



3-93 



The P-Machine 

GEREAL 
Opcode: 
Operation: 
Stack: 



r 



real 



Greater Than or Equal Real 
207 CF 

GEREAL 



<r SP 



: real : 

\ll II I II I II 1 1 I 
before 

Description: 



bool 

777777777777 
after 



<r SP 



The boolean result of the comparison TOS-1 >= TOS 
is pushed onto the stack. 



3-94 



0400101:03A 



The P-Machine 



GESTR 
Opcode: 
Operation: 
Stack: 



Greater Than or Equal String 
234 EA 

GESTR UB1, UB2 



addrjofs 



addr|ofs 

VlUIUflili 
before 

Description: 



<r SP 



bool 

1777777777777 
after 



<r SP 



UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a string (if the corresponding UB is zero) 
or to the offset of the string in the current 
segment. 



The boolean result of the comparison TOS-1 >= TOS 
is nushed on the stacks The b^tes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the shorter string is reached. The comparison 
begins at the second element of the strings. If 
there is a mismatch in any character position and 
the character in TOS-1 < the character in TOS, 
FALSE is pushed on the stack. Otherwise, the 
lengths of the strings are compared, and the 
boolean result of the comparison length(TOS-l) >= 
length(TOS) is pushed. 



0400101:03A 



3-95 



The P-Maehine 








GEUSW 


Greater Than or Equal Unsigned 


Opcode: 


181 B5 


Operation: 


GEUSW 


Staek: 




word 


<r SP 






word 


1 


bool 


<r SP 


VUIIUIIIII 
before 


after 




Description: 









The boolean result of the unsigned comparison 
TOS-1 >= TOS is pushed onto the stack. 



3-96 
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The P-Maehine 



INC 


Increment 


Opcode: 


231 


E7 


Operation: 


INC 


B 


Stack: 


<r SP 




addr 


addr 


\llflllltllll 
before 


//////////// 
after 


Description: 







<r SP 



The word pointer TOS is indexed by B words, and 
the resulting pointer is pushed. 



0400101:03A 



3-97 



The P-Machine 






INCI 


Increment Integer 


Opcode: 


237 


ED 


Operation: 


INCI 




Stack: 


<r SP 




int 


int 


\lllHIIUlll 


vimuiiiu 


before 




after 


Description: 







<- SP 



TOS is incremented by 1. If TOS was initially 
32767, the result should be -3.2768. 



3-98 



0400101:03A 



The P-Machine 



IND 


Index 




Opcode: 


230 


HG 


Operation: 


IND 


B 


Stack: 


<r SP 




addr 


word 


Vtllilllilll 


\iiiuiimu 


before 




after 


Description: 







<r SP 



TOS is the address of a record, 
with word B of the record. 



TOS is replaced 



0400101:03A 



3-99 



The P-Maehine 






INN 


Set Membership 


Opcode: 


218 


DA 


Operation: 


INN 




Stack: 


<r SP 

1 




int 








: set 

\iiiiiinuii 

before 


bool 


\iimumu 

after 


Description: 







<r SP 



The boolean result of the cheek whether TOS is 
contained in the set TOS-1 is pushed onto the 
stack. 



3-100 



0400101:03A 







The P-Machine 


INT 


Set 


Intersection 


Opcode: 


220 


DC 


Operation: 


INT 




Stack: 


\<r SP 

i 
i 




1 1 
: set : 




: set : 


1 \<r SP 
: set : 


\iuiuuun\ 




\uiimuu\ 


before 




after 


Description: 







The intersection (bit-wise AND) of sets TOS and 
TOS-1 is pushed onto the stack. 



0400101:03A 
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The P-Machine 








IXA 


Index 


Array 


Opcode: 


215 


D7 


Operation: 


IXA 


B 


Stack: 


<r SP 




word 






addr 




addr 


VIUIIIIUU 
before 


VllHIUHII 
after 


Description: 









<r SP 



TOS is an integer index. TOS-1 is the array base 
pointer. B is the size (in words) of an array 
element. The word pointer to the indexed element 
is pushed. 

Algorithm: 

addr:= TOS-1 + TOS*B * x 

(Where x=2 for byte-addressed PMEs, and x=l for 
word-addressed PMEs.) 
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0400101:03A 



The P-Maehine 



IXP 


Index 


Packed Array 


Opcode: 


216 


D8 


Operation: 


IXP 


UB1, UB2 


Stack: 


<- SP 




word 




1 1 


addr 


: pack-ptr : 


VIIUIUIIII 
before 


\miin//ui 

after 


Description: 







4- SP 



TOS is an integer index. TOS-1 is the array base 
pointer. UB1 is the number of elements per word. 
UB2 is the field width (in bits). A packed field 
pointer to the indicated field is pushed. 

Algorithm: 

pack-ptr.rightj>it:= (TOS mod UB1) * UB2 

pack-ptr.field_width:= UB2 

pack-ptr . addr := TOS-1 + (TOS div UB1) * x 

(Where x=2 for byte-addressed PMEs, and x=l for 
word-addressed PMEs.) 



0400101:03A 



3-103 



The P-Machine 








LAE 


Load 


Extended Address 


Opcode: 


155 


9B 


Operation: 


LAE 


UB, B 


Stack: 


<r SP 










addr 


\ii ui i mm \ 

before 


1111111111111 
after 


Description: 









<r SP 



The address of the variable with offset B in the 
global aetivation record of local segment UB is 
pushed onto the stack. 



3-104 



0400101:03A 







The P-Machine 


LAND 


Logical And 


Opcode: 


161 Al 


Operation: 


LAND 


Stack: 




word 


<r SP 






word 




word 


<r SP 


vumiiiiu 


v/iunum 




before 


after 


Description: 









TOS and TOS-1 are ANDed bit-wise, and the result 
is placed on the stack. 



0400101:03A 
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The P-Maehine 






LAO 


Load Global Address 


Opcode: 


134 


86 


Operation: 


LAO 


B 


Stack: 


<r SP 






addr 


viiiiiiiiun 

before 


\numiim 

after 


Description: 







<r SP 



The address of the variable with offset B in the 
global activation record is pushed onto the stack. 
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0400101:03A 



The P-Machine 



LCO 


Load 


Constant Offset 


Opcode: 


130 


82 


Operation: 


LCO 


B 


Stack: 


<r SP 










offset 


\ii iii/miu i 

before 


vmuiiim 

after 


Description: 









<r SP 



B is a word offset into the constant pool of the 
current segment. The address of the indicated 
constant is converted into a segment relative 
offset. This offset is a word offset on 

word-addressed PMEs and a byte offset on 
byte-addressed PMEs. The computed offset is 
pushed onto the stack. 



0400101:03A 
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The P-Machine 








LDA 


Load 


Intermediate Addi 


Opcode: 


136 


88 


Operation: 


LDA 


DB, B 


Stack: 


<r SP 










addr 


\IIUUIUIII\ 
before 


after 


Description: 









<r SP 



DB indicates the number of static links to traverse 
to find the activation record to use. (DB=0 
indicates the local activation record; DB=1 
indicates the parent activation record; and so 
forth.) The address of the variable with offset B 
in the indicated activation record is pushed onto 
the stack. 
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0400101:03A 









The P-Machine 


LDB 


Load 


Byte 


Opcode: 


167 


A7 


Operation: 


LDB 




Stack: 


<r SP 

» 

1 




1 








: byte-ptr 
before 




word 


<r SP 




VlllllIIUIl 
after 




Description: 











TOS is a byte pointer. TOS is replaced by the 
indicated byte with the high byte zero. 



0400101:03A 
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The P-Maehine 






LDC 


Load 


Constant 


Opcode: 


131 


83 


Operation: 


LDC 


UB1, B, UB2 


Stack: 








1 \<r 

: block : 

\nniiiuiu\ 

after 


I///////////7I 
before 


<r SP 


Description: 







If less than UB2+20 words are available on the 
stack, a stack fault is issued. 

B is a word offset into the constant pool of the 
currently executing segment. UB2 words starting 
at that offset are pushed onto the stack, preserving 

i.1 3 i? Al _ — *J_ T.P TTT11 i.l — — J— i— ft 

me uruer ui uie wwus, u. udj, uie muuc, is ^, 

and the current segment is of opposite byte sex 
from the host processor, the bytes of each word 
are swapped as they are loaded. 



3-HO 



0400l0l:03A 



The P-Machine 



LDCB 


Load Constant Byte 


Opcode: 


128 80 


Operation: 


LDCB UB 


Stack: 








<r SP 


UB 


\iimuu//i\ 

before 


VUIIUUIU 
after 


Description: 







<r SP 



The constant UB with high byte zero is pushed 
onto the stack. LDCB is used to load a constant 
in the range through 255. 



0400101:03A 



3-111 



The P-Machine 






LDCI 


Load Constant Integer 


Opcode: 


129 


81 


Operation: 


LDCI 


W 


Stack: 


<r SP 






W 


Minimi / ii \ 

before 


Vlllllllllll 
after 



«- SP 



Description: 

The constant word W is pushed onto the stack. 
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0400101:03A 



The P-Machine 



LDCN 


Load Constant NIL 


Opcode: 


152 98 


Operation: 


LDCN 


Stack: 








<r SP 


NIL 


\m nun m \ 

before 


vmmimi 

after 


Description: 







<r SP 



The processor-dependent value NIL is pushed onto 
the stack. See the table below for the value of 
NIL for each processor. 



NIL 



Z80 


0001 


8080 


0001 


6502 


0000 


6809 


0000 


68000 


0000 


HP-87 


0000 


PDP-11 


F001 


9900 


0000 


8086 


0000 



0400101:03A 



3-113 



The P-Machine 




LDCRL 


Load Constant Real 


Opcode: 


242 F2 


Operation: 


LDCRL B 


Stack: 






1 1 <- SP 

: real : 

after 


\iiumniu\ 

before 


Description: 





The real constant at offset B in the constant pool 
of the currently executing segment is loaded onto 
the stack. 
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0400101:03A 



The P-Machine 



LDE 


Load 


Extended 


Opcode: 


154 


9A 


Operation: 


LDE 


UB, B 


Stack: 


<r SP 










word 


\lil lilt Hill \ 
before 


VIUUIIUII 
after 


Description: 









<r SP 



The word at offset B in the global activation 
record of local segment UB is pushed onto the 
stack. 



0400101:03A 
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The P-Machine 






LDL Load 


Local 


Opcode: 135 


87 


Operation: LDL 


B 


Stack: 










word 


V///////////\<rSP 

before 


\HIUUIIIU 
after 


Description: 







<r SP 



The word with word offset B in the local 
activation record is pushed onto the stack. 
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0400101:03A 







The P-Machine 


LDM 


Load 


Multiple 


Opcode: 


208 


DO 


Operation: 


LDM 


UB 


Stack: 


<r SP 






1 " ~~~ \<r SP 


addr 


: bloek : 
\lHlllllllll\ 


VlUlllllllI 


before 




after 


Description: 







If less than UB+20 words are available on the 
stack, a stack fault is issued. 

TOS is a pointer to a block of UB words. The 
block is pushed onto the stack, preserving the order 
of the words. 



0400101:03A 



3-117 



The P-Machine 








LDO 


Load 


Global 


Opcode: 


133 


85 


Operation: 


LDO 


B 


Stack: 


<r SP 










word 


\ii milium 

before 


VI////IIII/I 
after 


Description: 









<- SP 



The word with offset B in the global activation 
record is pushed onto the stack. 
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0400101:03A 









The P-Maehine 


LDP 


Load 


Packed 


Opcode: 


201 


C9 


Operation: 


LDP 




Stack: 


\<r SP 




1 








: pack-ptr 

\uiiuimi 

before 




word 


<- SP 




VlllllilllJI 
after 




Description: 











The packed field pointer TOS is replaced with the 
field it designates. Before being pushed onto the 
stack, the field is right-justified and zero-filled. 



0400101:03A 
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The P-Maehine 








LDRL 


Load 


Real 




Opcode: 


243 




F3 


Operation: 


LDRL 






Stack: 


<r SP 








1 

• 


1 


addr 


real : 


vumiiiiu 

before 


'uimiii 1 

after 


Description: 









]<- SP 



TOS is the address of a real variable, 
replaced with the indicated real. 



TOS is 



3-120 



0400101:03A 



The P-Machine 

LEBYT Less Than or Equal Byte Array 

Opcode: 186 BA 

Operation: LEBYT UB1, UB2, B 

Stack: 

I ' \<- SP 

: addrlofs : 



\r 



addrlofs : | 

. bool 

777777777771 777777777777 



<r SP 



before after 

Description: 

UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a byte array (if the corresponding UB is 
zero) or to the offset of the byte array in the 
current segment. B is the size (in bytes) of the 
arrays. 

The boolean result of the comparison TOS-1 <= TOS 
is pushed on the stack. The bytes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the arrays is reached. If there is a mismatch and 
the character in TOS-1 > the character in TOS, 
FALSE is pushed onto the stack. Otherwise, TRUE 
is pushed. 



0400101:03A 3-121 



The P-Machine 

LEPWR 
Opcode: 
Operation: 
Stack: 



set 



Less Than or Equal Set 
183 B7 

LEPWR 



l<r SP 



: set 

Vmrmrm 

before 



bool 

1777777777777 
after 



<r SP 



Description: 

TRUE is pushed if TOS-1 is a subset of TOS. 
Otherwise, FALSE is pushed. 
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0400101:03A 
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LEQI 


Less Than or Equal Integer 


Opcode: 


178 


B2 


Operation: 


LEQI 




Stack: 


<r SP 




int 






int 


bool 


<r SP 


Villll/lllll 


\lillllllllll 




before 




after 


Description: 









The boolean result of the signed comparison 
TOS-1 <= TOS is pushed onto the stack. 



0400101:03A 
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LEREAL 
Opcode: 
Operation: 
Stack: 



real 



Less Than or Equal Real 
206 CE 

LEREAL 



14- SP 



: real 

\lllllHlUll 
before 



bool 

1777777777777 
after 



<r SP 



Description: 

The boolean result of the comparison TOS-1 <= TOS 
is pushed onto the stack. 
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LESTR 
Opcode: 
Operation: 
Stack: 



Less Than or Equal String 
233 E9 

LESTR UB1, UB2 



addr|ofs 



addrlofs 



1777777777777 
before 

Description: 



<r SP 



bool 

777777777777 
after 



4r SP 



UB1 and UB2 are mode flags. They refer to TOS 
and TOS-1, respectively. TOS and TOS-1 each 
point to a string (if the corresponding UB is zero) 
or to the offset of the string in the current 
segment. 

The boolean result of the comparison TOS-1 <= TOS 
is pushed onto the staek= The fcwtes are compared 
one by one in the natural byte order of the 
processor until a mismatch is found or the end of 
the shorter string is reached. The comparison 
begins at the second element of the strings. If 
there is a mismatch in any character position and 
the character in TOS-1 > the character in TOS, 
FALSE is pushed onto the stack. Otherwise, the 
lengths of the strings are compared, and the 
boolean result of the comparison length(TOS-l) <= 
length(TOS) is pushed. 
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LEOSW 


Unsigned Less Than or Equal 


Opcode: 


180 B4 


Operation: 


LEUSW 


Stack: 





word 



word 

1777777777777 
before 

Description: 



<- SP 



bool 

1777777777777 
after 



<r SP 



The boolean result of the unsigned comparison 
TOS-1 <= TOS is pushed onto the stack. 
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LLA 


Load 


Local Address 


Opcode: 


132 


84 


Operation: 


LLA 


B 


Stack: 


<r SP 










addr 


\in win in \ 


\mimmu 


before 




after 


Description: 









<r SP 



The address of the variable with offset B in the 
local activation record is pushed onto the stack. 
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LNOT 


Logical Not 


Opcode: 


229 E5 


Operation: 


LNOT 


Stack: 






word 


<r SP 


word 


\iiiiiiniui 


VIIIIIHIUI 



<r SP 



after 



before 
Description: 

TOS is replaced by its one's complement. 
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LOD Load 


Intermediate 


Opcode: 137 


8S 


Operation: LOD 


DB, B 


Stack: 












word 


<r SP 


1777/7/7/7/7 1 «- SP 


viiimiuii 




before 


after 


Description: 









DB indicates the number of static links to traverse 
to find the activation record to use. (DB=0 
indicates the local activation record; DB=1 
indicates the parent activation record; and so 
forth.) The word with offset B in the indicated 
activation record is pushed onto the stack. 
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LOR 


Logical Or 


Opcode: 


160 


Operation: 


LOR 


Stack: 





A0 



word 



word 

1777777777777" 
before 

Description: 



<r SP 



word 

1777777777777 
after 



<r SP 



TOS and TOS-1 are ORed bit-wise, and the result 
is placed on the stack. 
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LPR 


Load 


Processor Register 


Opcode: 


157 


9D 


Operation: 


LPR 




Stack: 


<r SP 








int 




word 


<r SP 


y/uuiiuu 


Vliillilllll 




before 




after 


Description: 











TOS is a register number. The value of the 
register indicated in TOS is pushed onto the stack. 
If TOS is negative, the following table indicates 
which register is pushed: 



-1 


CURTASK 


-2 


EVEC 


-3 


READYQ 



If TOS is positive, the current p-machine registers 
are saved in the TIB, and TOS is the word index of 
the register in the TIB to be pushed. If TOS is 
less than -3 or greater than the size of a TIB, the 
result of LPR is undefined. 
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LSL 


Load 


Static Link 


Opcode: 


153 


99 


Operation: 


LSL 


DB 


Stack: 


<r SP 










addr 


Minimum 

before 


Vlll/llll/ll 
after 


Description: 









<r SP 



DB indicates the number of static links to traverse. 
A pointer to the MSCW that is DB links above the 
current MSCW is pushed onto the stack. 
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MODI 


Modulo Integers 


Opcode: 


143 8F 


Operation: 


MODI 


Stack: 




int 


<r SP 






int 




int 


<- SP 


]//////////// 


viimiuui 




before 


after 


Description: 









If TOS is zero, a divide-by-zero execution error 
occurs. 

Otherwise, TOS is replaced by TOS-1 MOD TOS, 
where the MOD operation is as follows. The MOD 
operation is undefined if TOS is negative, but the 
PME shouldn't cause an execution error. The result 
of MOD is always an integer between and 
(TOS) - 1. This result is calculated as if TOS 
were added or subtracted from TOS-1 until the 
result is in the desired range. Note: the result of 
the MOD operation isn't really the remainder of the 
DIV operation if TOS-1 is negative. 
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MOV Move 

Opcode: 197 

Operation: MOV 
Stack: 

addrlofs ' *~ SP 



C5 

UB, B 



addr 

777777777777 
before 

Description: 



17777777777771 <- sp 
after 



TOS is either the address of a word block (if 
UB=0) or the offset of a constant word block in 
the current segment (if UBOO). B words are 
moved from the source designated by TOS to the 
destination address TOS-1. IF UB=2, and the 
current segment has opposite byte sex from the 
host processor, the bytes of each word are swapped 
as the words are moved. 
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MPI 


Multiply Integer 


Opcode: 


140 


8C 


Operation: 


MPI 




Stack: 


<r SP 




int 






int 


int 


<r SP 


\llllllllllll 


\iuiiimm 




before 




after 


Description: 









TOS is replaced by TOS-1 * TOS. The result 
should be computed as if it were an unsigned 
operation on 32-bit operands, and only the lowest 
16 bits were retained for the result. 
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MPR 


Multiply Real 


Opcode: 


194 


Operation: 


MPR 


Stack: 





C2 



real 



1<- SP 



: real 

\imiiuiui 

before 



I \<r SP 

: real : 

\muumu\ 

after 



Description: 

TOS is replaced by the value TOS-1 * TOS. The 
result must be zero on underflow. A floating point 
execution error is issued on overflow. 
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NAT Enter 


Native Code 


Opcode: 168 


A8 


Operation: NAT 




Stack: 




VI/ll/l/l/lli<rSP 

before 


MIIII II II III \<r SP 

after 


Description: 





Control is transferred to the native code that 
begins directly after the NAT instruction. It may 
be necessary to increment IPC to a word boundary 
on word-oriented processors. 
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NAT-INFO 
Opcode: 
Operation: 
Stack: 



Native Code Information 
169 A9 

NAT-INFO B 



1777777777777 
before 

Description: 



<-SP 17777777777771 <-sp 
after 



IPC is incremented to B bytes beyond the byte 
starting just after B in the p-code stream. The 
bytes after B contain information for the 
native-code generators. This instruction acts like a 
long form of NOP or a forward jump. 
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T j 


le P-Machine 


NEQI 


Not Equal Integer 




Opcode: 


177 


Bl 




Operation: 


NEQI 






Stack: 


<r SP 






int 




int 


bool 


<r SP 


vunii/nii 

before 


h/iiiiiiiu 

after 




Description: 









The boolean result of the comparison TOS-1 <> TOS 
is pushed onto the stack. 
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NFJ 


Not Equal False Jump 


Opcode: 


211 D3 


Operation: 


NFJ SB 


Stack: 




int 


<r SP 


int 




Vlllllllllil 
before 


mi mm mi \<r sp 

after 


Description: 





If TOS = TOS-1, a jump is made, relative to the 
next instruction, by the byte offset SB. 
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NGI 


Negate Integer 


Opcode: 


225 


El 


Operation: 


NGI 




Stack: 


<r SP 






int 


int 


<r SP 


viiuuimi 

before 


\iimimiii 

after 




Description: 









TOS is replaced by the negative (two's complement) 
of TOS. If TOS was initially -32768, the result 
should be -32768. 
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NGR 
Opcode: 
Operation: 
Stack: 



Negate Real 
228 E4 

NGR 



: real 

\iiiuimm 

before 



~f<- SP 



r 



real 

\inm/iiiu I 

after 



l<r SP 



Description: 

TOS is replaced by the inverse of TOS. 
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NOP No Operation 

Opcode: 156 9C 

Operation: NOP 
Stack: 

17777777777771 <rSP 17777777777771 «- sp 
before after 

Description: 

No operation is performed. Execution continues. 
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RESERVE1..RESERVE6 Reserved 

Opcode: 250..255 FA..FF 

Operation: RESERVEn 

Stack: 



7777777777771 <-sp 17777777777771 <- sp 
before after 

Description: 

RESERVEn generates an unimplemented instruction 
execution error. 

These opcodes are reserved for internal use by the 
compilers. 
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RND 


Round Real 


Opcode: 


ISi 


t$F 


Operation: 


RND 




Stack: 


<r SP 

1 




1 






: real 

\minuui 


int 


<r SP 


Vlllllllllll 




before 




after 


Description: 









Real TOS is converted to an integer by rounding, 
and the result is pushed on the stack. If the 
result isn't in the range -32768 to 32767, a floating 
point execution error is issued. 
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RPU 


Return 


from 


Procedure 


Opcode: 


150 




96 


Operation: 


RPU 




B 


Stack: 


<r SP 






1 1 
: MSCW : 

1 1 




1 1 
: data : 




: params : 

\llllUlllll 1 
before 




l////////////l<-SP 
after 



Description: 

Execution returns to the calling procedure. 

The E_Rec pointer in the MSCW indicates the 
segment to return to. If the segment isn't in 
memory, a segment fault is issued. 
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Otherwise, MP is set to the Dynamic_Link field of 
the MSCW. If the Proc field of the MSCW_ is 
positive, IPC is restored from the MSCW. 
Otherwise, IPC is set to the Exit_IC value found 
just before the procedure code in the segment. 
CURPROC is restored from the MSCW (negating the 
value, if necessary). If the E_Rec pointer of the 
MSCW differs from EREC, EREC and EVEC are set 
to reflect the new segment. 



0400101:03A 3-147 



The P-Machine 


. 




SBI 


Subtract 


Integer 


Opcode: 


163 


A3 


Operation: 


SBI 




Stack: 


<r SP 




int 




int 


int 


viimuuii 


\llllilllllll 


before 




after 


Description: 







<r SP 



TOS is replaced by TOS-1 - TOS. The result 
should be computed as if it were an unsigned 
operation on 32-bit operands, and only the lowest 
16 bits were retained for the result. Thus, 
overflow or underflow will "wrap around" to the 
opposite sign. 
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SBR 


Subtract Real 


Opcode: 


193 


CI 


Operation: 


SBR 




Stack: 


<r SP 




1 

: real : 




: real 


1 \<r SP 

: real : 


\iiii/uhiu 




\iiiimiu/i\ 


before 




after 


Description: 







TOS is replaced by the value TOS-1 - TOS. The 
result should be zero on underflow. A floating 
point execution error is issued on overflow. 
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SCIP1..SCIP2 
Opcode: 
Operation: 
Stack: 



Short Call Intermediate Procedure 
239..240 EF..F0 

SCIPn UB 



MSCW 



7<r SP 



: data 

Vrrnmrmr 

after 



17777777777771 4- SP 
before 

Description: 



Intermediate procedure UB in the currently 
executing segment is called. 

If the Data Size word for procedure UB is 
negative, nothing is allocated on the stack, and a 
native code call is made. P-code execution 

resumes with the following p-code. 

Otherwise, Data_Size words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the lexical parent (SCIP1) or 
grandparent (SCIP2) of the current MSCW. MP is 
set to point to the new MSCW, CURPROC is set to 
UB, and IPC is set to the first p-code of procedure 
UB. 
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If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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SCXG1..SCXG8 Short Call External Global 

Opcode: 112..119 70..77 

Operation: SCXGn UB 

Stack: 

I \<r SP 

: MSCW : 



data 



17777777777771 <- sp 
before 



\lflillUlill 
after 



Description: 

The global procedure UB in segment n is called. 

If segment UB isn't in memory, a segment fault is 



If the instruction is SCXG1 and the procedure 
number matches one of the standard procedure 
numbers, the p-code performs one of these standard 
procedures, instead of the call. See the section 
describing the standard procedures. 
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If the DataSize word for procedure UB is 
negative, nothing is allocated on the stack, and a 
native code call is made. P-code execution 

resumes with the following p-code. 

Otherwise, DataSize words and an MSCW are 
allocated on the stack. The Static_Link field of 
the MSCW is set to the new BASE (the global data 
MSCW). MP is set to point to the new MSCW, 
CURPROC is set to UB, and IPC is set to the 
first p-code of procedure UB. EREC and EVEC 
are set to reflect the new environment. 

If there aren't 40 words left on the stack after the 
MSCW and data are allocated, a stack fault is 
issued. 
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i 


SIGNAL 


Signal 


Opcode: 


222 DE 


Operation: 


SIGNAL 


Stack: 




addr 


<r SP 


Vllllll/llli 


\////////////\<rSP 


before 


after 


Description: 





TOS is the address of a semaphore. If the 
semaphore's wait queue is empty or the count is 
negative, the count is incremented by one. 
Otherwise, the TIB at the head of the semaphore's 
wait queue is put on the ready queue, and its 
Hang_Ptr is set to NIL. If the new task has a 
higher priority than the current task, a task switch 
occurs. 
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SIND0..SIND7 
Opcode: 
Operation: 
Stack: 



Short Index 
120..127 78..7 F 

SINDn 



addr 

1777777777777 
before 

Description: 



<r SP 



word 

1777777777777 
after 



<r SP 



TOS is the address of a record. TOS is replaced 
with word n of the record. SINDn is used to index 
into the first eight words of a record. The value 
of n is <opcode>-120. 
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SLDC0..SLDC31 Short Load Constant 
Opcode: 0..31 00..1F 

Operation: SLDCn 

Stack: 

| *" SP 

17777777777771 <-sp \ll I ll/UIIII 
before after 

Description: 

The constant word whose value is encoded in the 
opcode is pushed onto the stack. The value n is 
the value of the opcode itself. SLDCn is used to 
load a constant between and 31. 
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SLDL1..SLDL16 Short Load Local 
Opcode: 32..47 20..2F 

Operation: SLDLn 

Stack: 



7777777777771 ^sp 
before 

Description: 



word 

1777777777777 
after 



<r SP 



The word with word offset n in the local activation 
record is pushed onto the stack. SLDLn is used to 
load one of the first 16 local words. The value of 
n is <opcode>-31. 
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SLD01..SLD016 Short Load Global 
Opcode: 48..63 30..3F 

Operation: SLDOn 

Stack: 

word *" SP 

17777777777771 <-sp V7777777777T 
before after 

Description: 

The word with offset n in the global activation 
record is pushed onto the stack. SLDOn is used to 
load global words with offsets between 1 and 16. 
The value of n is <opcode>-47. 
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SLLA1..SLLA8 Short Load Local Address 
Opcode: 96..103 60..67 

Operation: SLLAn 

Stack: 

<- SP 



addr 



17777777777777^ sp 1777777777777 
before after 

Description: 

The address of the variable with offset n in the 
local activation record is pushed onto the stack. 
SLLAn is used to load the address of local 
variables with offsets between 1 and 8. The value 
of n is <opcode>-95. 
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SLOD1..SLOD2 Short Load Intermediate 

Opcode: 173..174 AD..AE 

Operation: SLODn B 

Stack: 



F77777777777"I«-sp 
before 

Description: 



word 

777777777777 
after 



<r SP 



The word with offset B in the activation record of 
the parent (SLOD1) or grandparent (SLOD2) of the 
local activation record is pushed onto the stack. 
The value of n is <opeode>-172. 
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SPR 


Store 


Processor Register 


Opcode: 


209 


Dl 


Operation: 


SPR 




Stack: 


<r SP 




word 




int 




\iimiumi 

before 


vim n urn i<- sp 

after 


Description: 







TOS-1 is a register number. If TOS-1 is negative, 

iuo 10 oiuicu ill viic ui cilfc; lOuywing i ogioid a* 



-1 CURT ASK 

-2 EVEC 

-3 READYQ 

Otherwise, the current p-machine registers are 
stored in the TIB. TOS is stored in the TIB at 
offset TOS-1. Finally, the p-machine registers are 
restored from the TIB. 
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i 




SRO 


Store 


Global 


Opcode: 


165 


A5 


Operation: 


SRO 


B 


Stack: 


<r SP 




word 




viiiuiiun 


\////////////\<rSP 


before 




after 


Description: 







TOS is stored in the word with offset B in the 
global activation record. 
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SRS 


Subrange Set 




Opcode; 


188 






Operation: 


SRS 






Stack: 


<r SP 






int 




1 

: set 

\miimu 

after 


\<r SP 


int 


• 

,.l 


VJUIIIIIIII 
before 


//I 



Description: 

If less than 20 words will be available on the stack 
after this operation, a stack fault is issued. 

The integers TOS and TOS-1 must be in the range 
[0 through 4097], If not, a value range execution 
error is issued. 

If TOS-1 > TOS. the enrntv set is oushed. 
Otherwise, a set is created containing the elements 
between TOS-1 and TOS, inclusive, as members. 
This set is pushed on the stack. 
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SSTL1..SSTL8 
Opcode: 
Operation: 
Stack: 



Short Store Local 
104..111 68..6F 

SSTLn 



word 

1777777777777 
before 

Description: 



<r SP 



17777777777771 <-sp 
after 



TOS is stored in the word with offset n in the 
local activation record. SSTLn is used to store in 
one of the first eight local words. The value of n 
is <opcode>-103. 
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STB 


Store Byte 


Opcode: 


200 C8 


Operation: 


STB 


Stack: 




word 


<r SP 


: byte-ptr : 

\l/UIUUU 
before 




i \miimiui\4rsp 

after 


Description: 





The low byte of TOS is stored in the location 
pointed to by byte pointer TOS-1. 
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STE Store 


Extended 


Opcode: 217 


D9 


Operation: STE 


UB, B 


Stack: 










word 


l////////////l<-SP 
before 


\jiuiiuiiii 

after 


Description: 







<r SP 



TOS is stored in the word with offset B in the 
global activation record of local segment UB. 
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STL 


Store 


Local 


Opcode: 


164 


A4 


Operation: 


STL 


B 


Stack: 


<r SP 




word 




Vlllllilllll 


l//7/////////l<-SP 


before 




after 


Description: 







TOS is stored in the word with offset B in the 
local activation record. 
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STM 


Store Multiple 


Opcode: 


142 8E 


Operation: 


STM UB 


Stack: 





block 



addr 



~I<- SP 



777777777777 
before 



\in 11 mi in i<- sp 

after 



Description: 

TOS is a block of UB words. The block is stored 
at address TOS-1, preserving the order of the 
words. 
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STO 


Store 




Opcode: 


196 


C4 


Operation: 


STO 




Stack: 


<r SP 




word 




addr 




Vllllllllili 
before 


l////////////l<-SP 
after 



Description: 

TOS is stored in the word pointed to by TOS-1. 
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STP 


Store 


Packed 


Opcode: 


202 


CA 


Operation: 


STP 




Stack: 


<r SP 

1 




word 




: paek-ptr : 

Vlillillllll 
before 




Ml III II II III \<r SP 
after 


Description: 







TOS contains right-justified data. TOS-1 is a 
packed field pointer. TOS is masked to the field 
width indicated in TOS-1, then stored into the field 
described by TOS-1. 
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STR 


Store 


Intermediate 


Opcode: 


166 


A6 


Operation: 


STR 


DB, B 


Stack: 


<r SP 




word 




VllUillllll 
before 


after 


Description: 







DB indicates the number of static links to traverse 
to find the activation record to use. (DB=0 
indicates the local activation record; DB=1 
indicates the parent activation record; and so 
forth.) TOS is stored into the word with offset B 
in the indicated activation record. 
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STRL 


Store Real 


Opcode: 


244 F4 


Operation: 


STRL 


Stack: 




1 

: real 


<r SP 


addr 




viiiuiiuii 

before 


Mil II IIIIIII \<r SP 

after 


Description: 





TOS is a real value. TOS-1 is an address. TOS is 
stored at the address TOS-1. 
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SWAP 


Swap 




Opcode: 


189 


BD 


Operation: 


SWAP 




Stack: 


<r SP 






word 


word 


<r SP 


word 


word 




Mlllllllllll 
before 


nnumm 

HI L6P 




Description: 









Word TOS is swapped with word TOS-1 on the 
stack. 
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TJP 


True 


Jump 


Opcode: 


241 


Fl 


Operation: 


TJP 


SB 


Stack: 


<r SP 




bool 




VIIIIIIIIIU 
before 


Vlllllllllll \<r SP 
after 


Description: 







If TOS is TRUE, a jump is made, relative to the 
next instruction, by the byte offset SB. 
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TNC 


Truncate 


Real 


Opcode: 


190 


BE 


Operation: 


TNC 




Stack: 


<r SP 




1 






: real 

\nmmiiu 

before 


int 


<r SP 




j/iii/ium 

after 




Description: 









Real TOS is converted to an integer by truncating, 
and the result is pushed onto the stack. If the 
result isn't in the range -32768 to 32767, a floating 
point execution error is issued. 
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UJP 


Unconditional Jump 


Opcode: 


138 


8A 


Operation: 


UJP 


SB 


Stack: 






before 


<r SP 


i//////////y/i<-sp 

after 


Description: 







A jump is made, relative to the next instruction, by 
the byte offset SB. 
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UJPL 


Unconditional Jump Long 


Opcode: 


139 


86 


Operation: 


UJPL 


W 


Stack: 






before 


1//////////// l> SP 
after 


Description: 







A jump is made, relative to the next instruction, by 
the byte offset W. 
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UNI 


Set 


Union 


Opcode: 


219 


DB 


Operation: 


UNI 




Stack: 


<r SP 




1 1 
: set : 




: set : 


1 1 
: set : 


before 




\llUJIIIIUI 1 
after 


Description: 







<r SP 



The union (bit-wise OR) of the sets TOS and TOS-1 
is pushed onto the stack. 
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WAIT 



Wait 



Opcode: 


z2o 


DF 


Operation: 


WAIT 




Stack: 


<r SP 




addr 




VIHIIIIIUI 


l////////////l>SP 


before 




after 


Description: 







TOS is the address of a semaphore. If the 
semaphore's count is greater than zero, the count 
is decremented by one. Otherwise, the current TIB 
is put on the semaphore's wait queue, its Hang_Ptr 
is set to TOS, and a task switch occurs. 
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XJP 


Case 


Jump 


Opcode: 


214 


D6 


Operation: 


XJP 


B 


Stack: 


<r SP 




int 




Vi/IIIIIIIII 
before 


l////////////l<-SP 
after 


Description: 







B is the offset of the case jump table within the 
constant pool of the current segment. TOS is the 
index. 

The case jump table is structured as follows: 



I limUH'Ull! 11 



W2 



table 



maximum index 



(W2-WD+1 word table 
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Every entry is an integer quantity in the byte sex 
of the current segment. If the current segment has 
opposite byte sex from the host processor, each 
word in the table must be flipped before it is used. 

If TOS is in the range Wl through W2, inclusive, a 
jump is made, relative to the next instruction, by 
the quantity in word (TOS - Wl) in the table. (The 
table is word-indexed starting with zero, and is 
found just after word W2 in the case jump table.) 
Otherwise, no jump is performed. 
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STANDARD PROCEDURES 

The standard procedures are procedures that are 
implemented in the PME directly, either for speed 
or because the nature of the procedure requires 
that it be written in native code. A standard 
procedure is called via a CXG or SCXG1 
instruction. Which procedure is executed is based 
on the procedure number. 

Most of the standard procedures require parameters 
on the stack, and some expect a function return 
value to be passed back. In some sense they act 
more like individual p-codes than procedures, 
because no RPU instruction is executed to return 
control to the caller. For this reason, the 
procedure descriptions that follow are presented in 
the same format as were p-code 
descriptions— showing the stack before and after 
execution. 
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UNIT I/O PROCEDURES 



UNITCLEAR 


(UNIT) 


Procedure: 


34 


Stack: 




int 


<r SP 


VllilllWIl 
before 




Description: 





V7T7TT77777T]<rSP 
after 



TOS is a unit number. The device with unit 
number TOS is initialized to its "power-up" state. 
On return, IORESULT contains status information. 
For more information on UNITCLEAR, refer to the 
BIOS documentation in Chapter 4. 
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UNITSTATUS (UNIT, STAT_REC, CONTROL) 
Procedure: 36 



Stack: 



int 



addr 



int 



1777777777777 
before 

Description: 



<r SP 



17777777777771 <-sp 
after 



TOS is the control word. TOS-1 is the address of 
a buffer. TOS-2 is the unit number. Status 
information about the unit described in TOS-2 and 
the direction described in TOS is written to the 
buffer, TOS-1. If TOS = the direction is output, 
If TOS = 1 the direction is input. On return, 
IORESULT contains status information. For more 
information about UNITSTATUS, refer to the BIOS 
documentation. 
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UNITREAD 
Procedure: 
Stack: 



(UNIT, BUF, LEN, BLOCK, CTRL) 
18 



int 



int 



int 



byte-ptr 



<r SP 



int 



777777777777 
before 

Description: 



17777777777771 <-sp 
after 



TOS is the control word. TOS-1 is the block 
number. TOS-2 is the number of bytes to read. 
TOS-3 is the address of the destination buffer. 

PTV*C< A 2*. *1~™ .._.'! 1 rrw l /» i • 

L\jc>—* a> tut: mill nuiiiuer. ine numDer oi Dytes 
specified in TOS-2 is read from unit TOS-4 at 
block TOS-1 into buffer TOS-3. The control word 
selects different modes of UNITREAD. On return, 
IORESULT contains status information. For more 
information about UNITREAD, refer to the BIOS 
documentation. 
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UNITWRITE (UNIT, BUF, LEN, BLOCK, CTRL) 

Procedure: 19 

Stack: 

'<r SP 



int 



int 



int 



: byte-ptr 



int 



1777777777777 
before 

Description: 



E777777777771<-sp 
after 



TOS is the control word. TOS-1 is the block 
number. TOS-2 is the number of bytes to write. 
TOS-3 is the address of the source buffer. TOS-4 
is the unit number. The number of bytes specified 
in TOS-2 is written to unit TOS-4 at block TOS-1 
from buffer TOS-3. The control word selects 
different modes of UNITWRITE. On return, 

IORESULT contains status information. For more 
information about UNITWRITE, refer to the BIOS 
documentation. 
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DNITWAIT 


(UNIT) 




Procedure: 


33 




Stack: 


<r SP 




int 




Vllillllllll 


\IHIIIIUUI\4r SP 


before 




after 


Description: 







TOS is a unit number. The p-maehine waits until 
all I/O on unit TOS is completed. On return, 
IORESULT contains status information. For more 
information about UNITWAIT, refer to the BIOS 
documentation. 
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UNITBUSY 
Procedure: 

Stack: 



int 







(UNIT): BOOLEAN 
31 



777777777777 
before 

Description: 



<r SP 



bool 

777777777777 
after 



<r SP 



TOS is the unit number. TOS-1 is a function 
return word. UNITBUSY returns TRUE if there is 
any outstanding I/O on device TOS, and FALSE 
otherwise. On return, IORESULT contains status 
information. For more information about 

UNITBUSY, refer to the BIOS documentation. 
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IORESULT 


:INTEGER 


Procedure: 


30 




Stack: 


<r SP 









int 


<r SP 


viiumiiii 


\IIIUIIUIU 




before 




after 


Description: 









TOS is a return word. IORESULT returns 
value of the p-maehine register IORESULT. 



the 
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IOCHECK 
Procedure: 23 

Stack: 



7777777777771 <rSP 7777777777771 <- sp 
before after 

Description: 

IOCHECK tests the p-machine register IORESULT 
for zero. If the register is nonzero, an I/O 
execution error is issued. 
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STRING PROCEDURES 



MOVELEFT 

Procedure: 

Stack: 



int 



: byte-ptr 



: byte-ptr 

Vmrmrrn 

before 
Description: 



(SOURCE, DEST, LENGTH) 
15 



<r SP 



17777777777771 <- sp 
after 



TOS is the number of bytes to move. TOS-1 is a 
pointer to the destination. TOS-2 is a pointer to 
the source. If TOS is zero or negative, no bytes 
are moved. Otherwise, the bytes are moved one at 
a time starting from the left (low order byte). 
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MOVERIGHT (SOURCE, DEST, LENGTH) 

Procedure: 16 

Stack: 

~ f 4- SP 

mt 



: byte-ptr 



: byte-ptr 



1777777777777 
before 

Description: 



17777777777771 <-sp 
after 



TOS is the number of bytes to move. TOS-1 is a 
pointer to the destination. TOS-2 is a pointer to 
the source. If TOS is zero or negative, no bytes 
are moved* Otherwise- the b^tes are moved one at 
a time starting from the right (high order byte). 
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FILLCHAR 
Procedure: 
Stack: 



int 



: byte-ptr 
: byte-ptr 

\iiuumiii 

before 



(DEST, LENGTH, CHAR) 
2i 



<r SP 



Mimiiuui i<-sp 

after 



Description: 

TOS is the character. TOS-1 is the length to fill. 
TOS-2 is the starting address for the fill. If 
TOS-1 is zero or negative, no filling is done. 
Otherwise, memory is filled with the byte TOS for 
TOS-1 bytes starting at address TOS-2. 
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SCAN 


(LEN, 


EXP, SOURCE): INT 


Procedure: 


22 




Stack: 


<r SP 




word 




: byte-ptr : 




byte 




bool 




int 













int 


<r S 


y/nmi/m 

before 


viiiiimui 

after 




Description: 











TOS is a mask field (unused). TOS-1 is a pointer 
to the array to scan. TOS-2 is the byte to look 
for. TOS-3 is the scan kind (0 means until equal, 
1 means until not equal). TOS-4 is the length to 
scan. If TOS-4 is negative, the scan proceeds to 
the left. TOS-5 is the function result word. 
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The array at TOS-1 is scanned in the direction 
indicated in TOS-4 until the character TOS-2 is 
found (TOS-3 = 0) or a nonmatching character is 
found (TOS-3 = 1) or until the length in TOS-4 is 
exhausted. The distance between the character 
where SCAN stopped and the start character is 
passed back as the function result. 
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COMPILER PROCEDURES 

TREESEARCH (ROOT, FOUNDP, TARGET): INT 

Procedure: 38 

Stack: 

Z \<- SP 

addr 



addr 



addr 







777777777777" 
before 

Description: 



int 

1777777777777 
after 



<r SP 



TOS is a pointer to the target string, which is a 
packed array of eight characters. TOS-1 is a 
pointer to where the result of the search will be 
saved. TOS-2 is a pointer to the root of the 
identifier tree to be searched. TOS-3 is the return 
word. 
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TREESEARCH searches the symbol table tree 
TOS-2 for the target string TOS, returning a 
pointer to where the target was found in the 
variable pointed to by TOS-1. If the target wasn't 
found, the variable pointed to by TOS-1 will point 
to the leaf node of the tree that was searched 
last. The function result returns status 

information: 

target was found 

1 target is to the right 
-1 target is to the left 

Each node of the tree contains the following fields 
at the indicated byte offsets: 

name (8 characters) 

8»;^,.v,+ lints /-»^;~+~..\ 
llgllL X1UK \pOlllLCi, 

10 left link (pointer) 
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IDSEARCH 
Procedure: 



(SYMREC, BUFFER) 
37 



Stack: 



addr 



addr 

1777777777777" 
before 

Description: 



<- SP 



17777777777771 <-sp 
after 



TOS is the address of a buffer. TOS-1 is the 
address of a record that has the following fields at 
the indicated byte offsets: 






SYMCURSOR 


2 


SY 


4 


OP 


6 


ID 



IDSEARCH scans the buffer at byte offset 
SYMCURSOR for an identifier (string beginning 
with a letter, containing letters, digits and 
underscores), ignoring underscores and masking 
lowercase to uppercase. The identifier is 

blank-filled to eight characters, then placed in ID 
for a maximum of eight characters. SYMCURSOR 
is updated to point just past the identifier. 
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Finally, the identifier is looked up in a table of 
reserved words, and its two characteristics are 
filled into SY and OP. If the identifier is not 
found in the table, SY is set to and OP is set to 
15. 

Here is the table of reserved words, along with the 
SY and OP values for each one: 

ID SY OP 



AND 


39 


2 


ARRAY 


44 


15 


BEGIN 


19 


15 


CASE 


21 


15 


CONST 


28 


15 


DIV 


39 


3 


DO 


6 


15 


DOWNTO 


8 


15 


ELSE 


3 


15 


END 


9 


15 


EXTERNAL 


53 


15 


FOR 


2 


15 


FILE 


46 


15 


FORWARD 


34 


15 


FUNCTION 


32 


15 


GOTO 


26 


15 


IF 


20 


15 


IMPLEMEN 


52 


15 


IN 


41 


14 


INTERFAC 


51 


15 


LABEL 


27 


15 


MOD 


39 


4 


NOT 


38 


15 


OF 


11 


15 


OR 


40 


7 


PACKED 


43 


15 


PROCEDUR 


31 


15 
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PROCESS 


56 


15 


PROGRAM 


33 


15 


REPEAT 


22 


15 


RECORD 


45 


15 


SET 


42 


15 


SEGMENT 


33 


15 


SEPARATE 


54 


15 


THEN 


12 


15 


TO 


7 


15 


TYPE 


29 


15 


UNIT 


50 


15 


UNTIL 


10 


15 


USES 


49 


15 


VAR 


30 


15 


WHILE 


23 


15 


WITH 


25 


15 
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CODE POOL PROCEDURES 

RELOCSEG (EREC) 

Procedure: 4 

Stack: 



addr 



1777777777777 
before 

Description: 



4r SP 



17777777777771 «- SP 
after 



TOS is the address of an E_Rec. RELOCSEG 
relocates the segment pointed to by the ERec. 
Since RELOCSEG is called after a segment is first 
read into memory, all relocation is performed. 
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MOVESEG 

Procedure: 

Stack: 



int 



addr 



addr 



1777777777777 
before 

Description: 



(SIB, SRCPOOL, SRCOFFSET) 
14 



<r SP 



\IIHI!llllll\<rSV 

after 



TOS is an offset to the segment within a code 
pool. TOS-1 is a pointer to a code pool descriptor 
of which the first two words are the pointer to the 
base of the pool. TOS-2 is the address of a SIB. 



MOVESEG moves the segment at offset TOS in the 
pool described by TOS-1 to the location specified 
in the SIB pointed to by TOS-2, and relocates it. 
Only segment-relative relocation is performed. 
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GETPOOLBYTES 

(DEST S POOLDESC, OFFSET, NBYTES) 



Procedure: 
Stack: 



int 



int 



addr 



addr 



1777777777777 
before 

Description: 



24 



<r SP 



17777777777771 <-sp 
after 



TOS is the number of bytes to get. TOS-1 is the 
offset within the pool of the bytes to get. TOS-2 
points to a code pool descriptor of which the first 
two words point to the pool. TOS-3 points to the 
buffer where the bytes will be placed. 

GETPOOLBYTES get TOS bytes from the pool 
described by TOS-2 at offset TOS-1, and places 
them at TOS-3. 



0400101:03A 



3-203 



The P-Machine 



PUTPOOLBYTES 

(SOURCE, POOLDESC, OFFSET, NBYTES) 



Procedure: 



25 



Stack: 



int 



int 



addr 



addr 



077777777777 
before 



<r SP 



17777777777771 <-sp 
after 



Description: 

TOS is the number of bytes to put. TOS-1 is the 
offset within the pool of the bytes to put. TOS-2 
points to a code pool descriptor of which the first 
two words point to the pool. TOS-3 points to the 
source buffer. 



PUTPOOLBYTES writes TOS bytes from the buffer 
TOS-3 to the pool described by TOS-2 at offset 
TOS-1. 
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FLIPSEGBYTES (EREC, OFFSET, NWORDS) 

Procedure: 26 

Stack: 



int 



addr 



777777777777 
before 

Description: 



17777777777777 <-sp 
after 



TOS is the number of words to flip, TOS-1 is the 
word offset within the segment where flipping will 
take place. TOS-2 is the address of the E_Rec 
describing the segment. 

FLIPSEGBYTES flips TOS words starting at word 
offset TOS-1 in the segment described by TOS-2. 
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READSEG 

Procedure: 

Stack: 



(EREC): INTEGER 
39 



addr 







777777777777 
before 

Description: 



<r SP 



int 

777777777777 
after 



<r SP 



TOS is the address of the ERec describing a 
segment. TOS-1 is the return word. 

READSEG reads the segment described by TOS into 
memory at the location described in the SIB. The 
completion code in p-machine register 10 RESULT is 
returned as the function result. 
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CONCURRENCY PROCEDURES 

QUIET 

Procedure: 27 

Stack: 



7777777777771 <rSP 17777777777771 <r SP 
before after 

Description: 

QUIET must disable all p-maehine events such that 
no attached semanhnre is sionnllprl until tht> 
corresponding call to ENABLE is made. 



ENABLE 

Procedure: 28 

Stack: 



7777777777771 <-sp 17777777777771 <- sp 
before after 

Description: 

ENABLE reenables p-machine events that have been 
disabled by QUIET. 
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ATTACH 

Procedure: 

Stack: 



(SEMAPHORE, VECTOR) 
29 



int 



addr 



C77777777777 
before 

Description: 



<r SP 



l////////////l<-SP 
after 



TOS is the number of a p-maehine event vector. It 
must be in the range through 63. TOS-1 is the 
address of a semaphore. 

ATTACH associates the semaphore pointed to by 
TOS-1 with the vector TOS such that whenever the 
event TOS is recognized, the semaphore is signaled. 
If the semaphore pointer is NIL, vector TOS must 
be unattached from any sempahore it was formerly 
attached to. If TOS isn't in the range through 
63, no operation is performed. 
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MISCELLANEOUS PROCEDURES 



TIME 


(HIWORD, LOWORD) 


Procedure: 


20 


Stack: 




addr 


<r SP 


addr 




\}U/IIIII/II 
before 


f l////////////l<-SP 
after 


Description: 





TOS is a pointer to where the high word of the 
time will be saved. TOS-1 is a pointer to where 
the low word of the time will be saved. 



TIME saves the high and low words of the system 
clock (a 32-bit 60 Hz clock) in the indicated words. 



0400101:03A 



3-209 



The P-Machine 

POWEROFTEN (POWER): REAL 
Procedure: 32 



Stack: 



int 





Vrmrmrn 

before 
Description: 



<- SP 



: real 

\imimiiu 

after 



<r SP 



TOS is a positive integer power. POWEROFTEN 
returns the real value ten to the power of TOS. If 
TOS < or TOS > the largest expressible power, a 
floating point execution error is issued. 
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LONG INTEGERS 

The long integer data type is a nonscalar data type 
unique to UCSD Pascal. Long integers may be up 
to 36 decimal digits long. Although they lack some 
of the flexibility of scalar types, long integers 
allow operations on integers outside the range of 
most microcomputers (generally, -32768 to +32767 
on a 16-bit machine). In computations, long 

integers act like real numbers; however, they act 
more like sets in the way they are implemented and 
in the way they are passed as parameters. 

Number Format 

On the stack (when used in calculations), long 
integers are of variable length, and consist of a 
length word followed by a number component. 
An integer five words long that is on the top of 
stack looks like this: 



SP — > I 5 I length word 

+ + 

t number I 

I component I five words of number 



rest of stack 



Every long integer on the stack has this format, 
regardless of the processor. However, the actual 
number encoding varies from processor to 
processor. The number format for different 
processors is given later in this section. 
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When a long integer is assigned to a variable, or 
stored in a file on disk, only the number 
component is present. The length word is 
present only when the number is on the stack. 
Each long integer variable is allocated a fixed 
number of words. When a long integer is 
assigned to a variable, the number must be 
coerced to the storage size of the variable. If 
this can't be done, an integer overflow execution 
error occurs. 

The storage size for long integers is from two to 
ten words, based on the number of digits 
specified in the declaration statement. The 
following table shows the allocation size for each 
declared size. 



digits 


size (words) 


1..4 


2 


5..8 


3 


9..12 


4 


is ir 


5 


17..20 


6 


21..24 


7 


25..28 


8 


29..32 


9 


33..36 


10 



3-212 0400101:03A 



The P-Maehine 



The declaration size reflects the approximate 
number of digits that may be stored in the 
number. Since long integer formats vary from 
processor to processor, more digits than the 
declared number of digits may sometimes be 
stored in a long integer variable. As a result, 
the overflow value for a long integer may vary 
from processor to processor. The fact that more 
digits than the declared size may be stored in a 
long integer variable shouldn't be relied upon, 
since it would reduce the portability of a 
program. The number of digits specified in the 
declaration of a long integer should be treated as 
the maximum number of digits that the number 
will ever hold. 



Long Integer Constants 

Long integer constants are constructed at 
run-time by code generated by the compiler. 
This code builds each constant by doing a series 
of calculations on integers, thus sidestepping the 
problems associated with the fact that long 
inteeer formats are Drocessor-deDendent. 

Example 1. To build the long integer constant 
12, the compiler generates code to do the 
following: 

CVTU2) 



where 12 is an integer constant, and CVT is the 
routine to convert an integer to a long integer. 
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Example 2. To build the long integer constant 
235543, the compiler generates code to do the 
following: 

CVT (23554) *CVT (10) + CVT(3) 

Example 3. To build -8733442, the compiler 
generates code to do the following: 

-( CVT(8733)*CVT(1000) + CVT(442) ) 



Here is a listing of the actual p-code generated 
for the last example. The long integer routines 
called to do each operation are described in 
detail later. 



42(02A) 


LDCI 


8733 




811D22 


45(02D) 


SLDC 


18 




12 


46(02E) 


SCXG 


LONGOPS 


2 


7202 


48(030) 


LDCI 


1000 




81E803 


51(033) 


SLDC 


18 




12 


52(034) 


SCXG 


LONGOPS 


2 


7202 


54(036) 


SLDC 


8 




08 












P51UJ/J 


OV.AVJ 


jjvwwro 


£. 


/ £UZ 


57(039) 


LDCI 


442 




81BA01 


60(030 


SLDC 


18 




12 


6K03D) 


SCXG 


LONGOPS 
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LONGOPS Routines 

LONGOPS is the Pascal UNIT that implements 
the long integer functions. LONGOPS contains 
three procedures: FREADDEC reads a long 
integer; FWRITEDEC writes a long integer; and 
DECOPS performs the long integer arithmetic 
functions. 

Although LONGOPS isn't part of the p-machine 
(it is in SYSTEM.LIBRARY), it isn't a normal 
Pascal UNIT either. Normally, a Pascal 
procedure or function must have fixed size 
parameters, where the parameter size is known at 
compile-time. There is one procedure in 
LONGOPS (DECOPS) that takes variable size 
parameters. One way to view this is that each 
call to DECOPS is like the execution of a single 
p-code in the PME. Different functions of 
DECOPS take different parameters and return 
different results, just as different p-codes do. In 
fact, DECOPS performs functions very similar to 
the set p-codes in the PME. 
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DECOPS Routines 

DECOPS is an external (assembly language) 
procedure in UNIT LONGOPS that performs the 
long integer functions. 

Parameters are passed to DECOPS on the stack. 
On every call, the stack looks as follows: 



+ + 

SP — > I return address I one or two words 

+ + 

I function code I one word 
+ + 

I ... I 

I parameters I variable size 

I ... I 

+ 4 

I ... I rest of stack 



The return address is the standard return 
information for any assembly-language routine. 
Refer to the assembler documentation for a 
description of this information. (The return 

oHH»»aoc icnH qIuiditc r\tt +r*r\ n-f +V*o otuml/ Ttio 

HP-87, for example, uses a separate stack.) 



The function code is a word that describes the 
function that is to be performed. The actions 
performed by each function are discussed below, 
along with the numeric value of the associated 
function code. Function codes are even integers 
between and 20. Even integers are used to 
facilitate jumping indirectly through a word array 
of addresses. 
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The parameters vary for each long integer 
function. The parameter requirements for each 
routine are included in the description of the 
routine. 

Usually, DECOPS returns to the PME as a normal 
assembly-language routine does. However, in 
certain error conditions, DECOPS must return to 
a different location in the PME so that an 
execution error may be recognized. This method 
of returning is usually via the .INTERP jump 
vector, but there are exceptions to this. 

Below are the descriptions of each routine in 
DECOPS. The first line of each description 
contains the function code, followed by a 
descriptive name of the function. Next are 
descriptions of the parameters and the return 
valuefe). Finally, there is a detailed description 
of the function, including any error conditions 
that should be recognized. 
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In the parameter and return value descriptions, 
the top of stack (TOS) is on the left, and items 
deeper on the stack are on the right. Here are 
the abbreviations used in the descriptions: 



LI Long Integer. A variable-length long 

integer, containing a length word. 
ALI Adjusted Long Integer. A fixed length 

long integer that does not contain a 

length word. 
W Word. A 16-bit quantity. 

B Boolean. A boolean quantity. 1=TRUE, 

0=FALSE. 



— Adjust 

parameters: <W> <LI> 
return val: <ALI> 



Adjusts <LI> into an adjusted long integer 
<ALI> suitable for assignment to a variable. 
It does this by stripping off the size word 
from <LI>, then expanding or contracting <LI> 
until it is <W> words in length. If a 
contraction can*t be done because of overflow, 
an integer overflow execution error occurs. 
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2 - Add 

parameters: <LI 2> <LI 1> 
return val: <LI 3> 

Adds <LI 1> and <LI 2>, placing the result on 
the stack as <LI 3>. If the result <LI 3> has 
more than 36 digits, an integer overflow 
execution error may occur. 

4 — Subtract 

parameters: <LI 2> <LI 1> 
return val: <LI 3> 

Subtracts <LI 2> from <LI 1>, placing the 
result on the stack as <LI 3>. If the result 
<LI 3> has more than 36 digits, an integer 
overflow execution error may occur. 
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6 — Negate 



parameters: <LI 1> 
return val: <LI 2> 



Negates <LI 1>, placing the result on the 
stack as <LI 2>. 



8 - Multiply 

parameters: <LI 2> <LI 1> 
return val: <LI 3> 



Multiplies <LI 1> and <LI 2>, placing the result 
on the stack as <LI 3>. If the result <LI 3> 
has more than 36 digits, an integer overflow 
execution error may oceur. 

10 — Divide 

narameters: <LI 2> <LI 1> 

AT 

return val: <LI 3> 

Divides <LI 1> by <LI 2>, placing the result on 
the stack as <LI 3>. If the result <LI 3> has 
more than 36 digits, an integer overflow 
execution error may occur. If <LI 2> is zero, 
a divide-by-zero execution error occurs. 
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12 — Long Integer to String 

parameters: <W 1> <W 2> <LI> 
return val: 



Converts <LI> into a string, placing the result 
at the location pointed to by <W 2>. <W 1> is 
the maximum length of the string. If <LI> 
requires more than <W 1> characters to 
represent, a string overflow execution error 
occurs. 

14 — TOS-1 Integer to Long Integer 

parameters: <LI 1> <W> 
return val: <LI 1> <LI 2> 

Converts the integer at TOS-1 <W> into a long 
integer <LI 2>, leaving the long integer at 
TOS <LI 1> unchanged. 
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16 — Compare 

parameters: <W> <LI 2> <LI 1> 
return val: <B> 

value of <W> comparison 

less than 

1 less than or equal 

2 greater than or equal 

3 greater than 

4 not equal 

5 equal 

Performs the comparison encoded in <W> of 
the long integers <LI 1> and <LI 2>, placing 
the boolean result <B> on the stack. In all 
cases, <LI 1> is compared to <LI 2>, in that 
order. 



18 — TOS Integer to Long Integer 

parameters: <W> 
return val: <LI> 



Converts the integer at TOS <W> into a long 
integer <LI>. 
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20 — Long Integer to Integer 

parameters: <LE> 
return val: <W> 

Converts a long integer <LI> into an integer 
<W>. If the conversion can't be made (<LI> 
isn't in the range -32768..32767), an integer 
overflow execution error occurs. 
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Processor-Specific Information 



8086/8088/LSI-11/6809/9900 

These processors use a two's complement 
format that is stored in natural byte order 
with the most significant bits appearing at the 
lowest byte address. The most significant bit 
represents the sign of the number; a means 
positive, and a 1 means negative. 

Examples (hexadecimal): 



0000 


0000 


6C33 


is 27699 


FFFF 


FFF6 




is -10 


0000 


0000 




is 



68000 

The 68000 uses a sign-magnitude Binary-Coded 
Decimal (BCD) format with the first word a 
sign word. The magnitude part of the long 
integer is stored in natural byte order, with 
the most significant digits in the byte with the 
lowest address, and the number is 
right-justified within the field. In the sign 
word, means positive, and FFFF means 
negative. 



Examples: 










00 00 00 


02 


76 99 


is 


27699 


FF FF 00 


10 




is 


-10 


00 00 00 


00 




is 





FF FF 00 


00 




is 


also 
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Z80/8080/6502 

These processors have the same format as the 
68000 except that only the least significant 
byte of the sign word is used (that is, 0000 
means positive, and FF00 means negative). 

Examples: 

0000 00 02 76 99 is 27699 
FF00 00 10 Is -10 

0000 00 00 is 



HP-87 

The HP-87 uses a ten's complement BCD 
format with the least significant digit 
appearing at the lowest address. A 9 in the 
most significant digit means negative, a 
means postive. 

Examples (least significant digit first): 



99 67 


20 


00 


is 27699 


09 99 


99 


99 


is -10 


00 00 


00 


00 


is 
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THE I/O SUBSYSTEM 

Besides emulating the p-machine, each PME must 
contain some native code to perform certain 
time-critical operations and deal with hardware 
dependencies such as I/O devices. The body of 
code that is not devoted to emulating p-code is 
called the Run-Time Support Package (RSP). The 
portion of the RSP that is responsible for I/O is 
caUed the RSP/IO. 

To make the system as portable as possible, the 
RSP/IO is machine-independent, except for a 
portion called the Basic Input/Output Subsystem 
(BIOS). The BIOS must vary depending on the 
hardware in use, but the interface between the 
BIOS and the RSP/IO is standard— calls to routines 
in the BIOS are clearly defined. 

Thus, we have the I/O hierarchy shown in Figure 
4-1, the user's I/O calls (that is, READLN, 
WRITELN) are mapped by the compiler and 
operating system into calls to the RSP (that is, 
UNITREAD, UNITWRITE). The RSP/IO itself calls 
the BIOS which controls the actual device 
operations. It is important for the reader to 
recognize that here we are discussing a synchronous 
I/O system. In other words, when an I/O request 
has been initiated by your program, control doesn't 
return to that program until the I/O operation is 
completed. 
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This chapter describes the behavior and interfaces 
of the RSP/IO and BIOS. The SBIOS (Simplified 
BIOS) is described in the Adaptable System 
Installation Manual . The easiest way to describe its 
relation to the BIOS and RSP/IO is to sketch the 
history of I/O support within the p-System. 

The first implementation was for the PDP-11, which 
has well-established standard interfaces to 
peripheral devices (regardless of manufacturer). In 
this environment, there was no need for I/O 
adaptation. 

When the p-System was adapted to the 8080 and 
Z80, the p-System used CP/M BIOS run-time to 
perform low-level I/O. As adaptations for 
additional processors (that is, the 9900 and 6502) 
were begun, however, it became clear that the 
p-System needed some analog to the CP/M BIOS. 
It was at this point that the p-System BIOS, 
essentially as described in this chapter, was created 
and standardized. 

The final step in this I/O development took place 
at SofTech Microsystems, where it was realized 
that: 

1. The BIOS definition didn't address the problem 
of standardizing bootstrap mechanisms; and 

2. Implementing a BIOS was a difficult task, and 
virtually required the use of an already running 
p-System. 
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The adaptable system was created to address these 
problems. The SBIOS is as simple a hardware 
interface as possible. It is called from a unit of 
"interface code" that aecepts BIOS-style calls and 
emits SBIOS routine calls. This interface code 
allows the PME/SBIOS interface to be simpler than 
the BIOS interface. The RSP/IO is essentially 
unchanged. 

The adaptable system also addresses the bootstrap 
problem by defining a hierarchy of bootstrap 
components, only some of which need to be 
implemented by the user installing a p-System. 

A user who has access to a running p-System and 
the source code for the PME and SBIOS interface 
code may wish to implement a BIOS-level I/O 
interface. This is potentially more efficient than 
an SBIOS-level adaptation, since the more elaborate 
BIOS interface allows the implementor to take 
advantage of such performance characteristics as 
Direct Memory Access (DMA) support in the disk 
interface. 



Both BIOS and SBIOS I/O interlaces have been 
created as the system was adapted to new 
environments. 
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"Language Level" 



A USER 
I 



THE SYSTEM 



I 



I 

I device no., data area address , 

Ibyte count 

|[, block no., control word] 



DEVICE I/O 
(parameter checking) 






IConsole IPrinter 


iDisk 


1 Remote 


lOser- 


V 


V 


1 


V 


1 defined 


SPECIAL 


CHAR SPECIAL CHAR 


1 SPECIAL CHAR 


1 Devices 


HANDLING HANDLING 


1 HANDLING 


1 


(DLEs,CRs 


,EOF (DLEs, CRs, EOF 


1 (DLEs 


CRs, EOF 


1 


& alpha 


Lock) & alphalock) 


1 & alphalock) 


1 


(write) 1 


Kread) 1 


Idrive no., 
Idata area 




Idevice no. , 
Idata area 


single 1 


1 single 1 single 


1 address, 


Isingle 


1 address, 


data 1 


Idata Idata 


Ibyte count 


Idata 


Ibyte count, 


byte 1 


Ibyte Ibyte 


1 logical 
1 block no. 

I 


Ibyte 


1 logical 
1 block no. 
1 


"BIOS 1 




1 




i ■ 


Level" 1 


1 V 


V 


V 


V 




1 PRINTER 


DISK SERIAL LINE 


MISCELLANEOUS 




1 PRIMITIVES 


MAPPER PRIMITIVES 


DEVICE 




+ + 

1 


(Map logical 
blocks into 




DRIVERS 




V 


track & sector) 








TYPE-AHEAD 


1 








QDEUE 
1 


V 

DISK 








V 


PRIMITIVES 








HANDLING 










(start/stop, flush, break) 
1 






V 

SCREEN 


V 
KEYBOARD 








PRIMITIVES PRIMITIVES 









Figure 4-1. I/O Subsystem Hierarchy 



4-6 



0400101:04A 



Low-Level I/O 



0400101:04A 4-7 



Low-Level I/O 



DEVICE I/O ROUTINES 

As mentioned above, all language-level I/O requests 
are eventually mapped by the compiler and 
operating system into calls to a group of intrinsic 
routines known as the device I/O routines. The 
programmer may call the device routines directly, 
or may use the standard I/O syntax of the language 
in use. The exact details of how this mapping is 
accomplished don't concern us here. The device 
I/O routines aren't written in Pascal, but are the 
native code procedures that constitute the RSP/IO. 

Throughout this chapter, it is assumed that all I/O 
support at or below the device I/O level is 
implemented in assembly language. If p-code is the 
native language of the host processor, these 
routines may be implemented in Pascal. 

The RSP/IO routines are implemented and accessed 
as routines of the operating system's unit KERNEL. 
KERNEL is accessible as segment 1 of every 
compilation unit. The actual code for the routines 
may reside in the PME itself, instead of in 
KERNEL. 
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Calling the RSP/IO 

If you make direct calls to device I/O routines, 
they look like any other intrinsic routine. If 
they actually were declared in Pascal, the 
declarations would have the following format 
(allowing a few illegitimate constructs such as 
optional parameters and variable-length arrays): 



PROCEDURE UNITREAD( UNITNUMBER : INTEGER; 

VAE DATAAREA : PACKED ARRAY [0 . .BYTESTOTRANSFER-1] 

OF 0..255; 
BYTESTOTRANSFER : INTEGER 
I; LOGICALBLOCK : INTEGER] 
[ ; CONTROL : INTEGER] ) ; 

PROCEDURE UNITWRITEI <same as for UNITREAD> ) ; 

FUNCTION UNITBUSYt UNITNUMBER : INTEGER ) : BOOLEAN; 

PROCEDURE UNITWAITt UNITNUMBER : INTEGER ) ; 

PROCEDURE UNITCLEARf UNITNUMBER : INTEGER ); 

PROCEDURE UNITSTATUSt UNITNUMBER : INTEGER; 

VAR STATUSWORDS : ARRAY [0..29] OF INTEGER; 
CONTROL : INTEGER ) ; 



Remember that no such declarations actually 
exist in the system. They are intended to model 
the parameters passed and returned by the native 
code RSP/IO routines. 
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Devices and Device Numbers 

Each device is referred to in the system by a 
given number. The formal parameter 

UNITNUMBER in the declarations above 
determines which physical device the operation 
is intended for. Thus, the device I/O routines 
are device-transparent to the Pascal 
programmer; the same procedure will handle 
any physical device. Figure 4-2 is a list of 
the predefined device numbers associated with 
each physical device. The meaning of the 
other parameters is discussed later in this 
chapter. 



Device Numbe 


r Volume Name 







<Reserved for the system> 


1 




CONSOLE 


2 




SYSTERM 


3 




<Reserved for the system> 


4 




diskO 


5 




diskl 


6 




PRINTER 


7 




REMIN 


8 




REMOUT 


Q 




disk 2 


10 




dlsk3 


11 




disk4 


12 




disk5 


13 - 


• 127 


Additional disks, subsidiary volumes 
and user-defined serial devices 

Figure 4-2. Device Numbers 



User-Defined Devices 

The system reserves all device numbers above 

127 for user-defined devices. They have no 
preassigned names, but can be accessed through 

the UNIT intrinsics as can devices with 
preassigned numbers. 
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CONTROL Parameters 

The CONTROL parameter to UNITREAD, 
UNITWRITE, and UNITSTATUS is a word used 
to pass special information to the RSP/IO and 
BIOS regarding the handling of the I/O request. 
The formats of the CONTROL words are shown 
in Figures 4-3 and 4-4. ("Set" equals 1; 
"reset" equals 0.) 



MSB 

15-13 

USER 

DEFINED 



Value 



12-4 
(Reserved) 



3 
NOCRLF 



2 

NOSPEC 
4 



PHYSSECT 
2 





ASYNC 

1 



Figure 4-3. CONTROL Word Format 

fnr» TTXTTTPTJAn onH TTWTTWTJTTT? 

*- vs. v mi iv^lix/ Vkll-W* V 111 1 II JLfeX X JL4 



Bit ASYNC 



Bit 1 
PHYSSECT 



Set implies asynchronous I/O 
request. Reset implies 

synchronous I/O request. (This 
bit should always be reset.) 

Set implies "physical sector 
mode" for disk I/O. Reset 
implies "logical block mode" for 
disk I/O. 



Bit 2 NOSPEC Set implies "no special 
character handling." Reset 

implies "special character 
handling." 
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Bit 3 NOCRLF Set implies that no line-feeds 
(LFs) are to be appended to 
carriage returns (CRs) during 
nondisk I/O. Reset implies LFs 
are to be appended to CRs 
during nondisk I/O. 

Bits 4-12 Reserved for future expansion. 

Bits 13-15 User-defined functions. 



The default setting for all these bits is reset 
(0). 



MSB 

15-13 
USER 
I DEFINED 



Value 



12-1 
(Reserved) 




IODIR 

1 



Figure 4-4. CONTROL Word Format 



Bit IODIR Set implies the status of the 
input channel is to be 
returned. Reset implies the 
status of the output channel is 
to be returned. 

Bits 1-12 Reserved for future expansion. 

Bits 13-15 User-defined functions. 
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IORESULT and Completion Codes 

At times, an I/O request will terminate 
abnormally. To handle error conditions, a 

program may use the intrinsic IORESULT. The 
integer value returned by IORESULT describes 
the status of the last I/O request. 

Each call to UNITREAD, UNITWRITE, 
UNITCLEAR, or UNITSTATUS causes a 
"completion code" to be set in the SYSCOM data 
area (SYSCOM, for SYStem COMmunication area, 
is conventionally the only data space that may be 
directly accessed by both the operating system 
and the PME). Programmers may test the 
completion code by using IORESULT. 
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The standard completion codes are given in 
Figure 4-5 below. 

Code Meaning 

No error 

1 Bad block, CRC error (parity) 

2 Bad device number 

3 Illegal I/O request 

4 Data-com timeout 

5 Volume is no longer on-line 

6 File is no longer in directory 

7 Illegal file name 

8 No room; insufficient space on disk 

9 No such volume on-line 

10 No such file name in directory 

11 Duplicate file 

12 Not closed: attempt to open an open file 

13 Not open: attempt to access a closed file 

14 Bad format: error reading real or integer 

15 Ring buffer overflow 

16 Write attempt to protected disk 

17 Illegal block number 

18 Illegal buffer address 

19 Bad text file size 

20 - 127 Reserved for future expansion 

Codes 128 through 255 are available for 
non-predefined, device-dependent errors. 



Figure 4-5. I/O Completion Codes 



Logical Disk Structure 

The system views a disk as a zero-based linear 
array of 512-byte logical blocks. All disks in the 
system have this logical structure, regardless of 
their physical format. The physical allocation 
units of a disk are commonly known as sectors; 
these may vary widely from one model of drive 
to another. The BIOS is responsible for mapping 
the logical structure of a system disk onto the 
physical structure of the device; that is, mapping 
logical blocks onto physical sectors. 
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Physical Sector Addressing Mode 

To provide enhanced flexibility for systems 
programming at a machine-specific level, a 
mechanism has been provided for directly 
accessing the physical sectors of the disk. 
When the PHYSSECT bit (bit 1, value 2) of the 
CONTROL word is set on a call to UNITREAD 
or UNITWRITE involving a disk unit, the I/O is 
performed in physical sector mode. This has 
the following effects: 

1. The parameter LOGICALBLOCK is 
interpreted by the BIOS as the physical 
sector number (PSN). (In the future, this 
may become the least significant 15 or 16 
bits of the PSN.) 

2. The parameter BYTESTOTRANSFER must be 
0. (In the future, this may become the most 
significant 16 bits of the PSN.) 
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Physical Sector Numbers 

Typically, the physical sectors of a disk are 
addressed by specifying both track and sector 
numbers. That is, the disk is viewed as an 
array of tracks where each track is an array 
of sectors. If this data structure were 

declared in Pascal, it would look like this: 

type 

BYTE = 0. .255; 

SECTOR = array [0 . . (BYTESperSECTOR-1) ] of BYTE; 
TRACK = array [1. .SECTORSperTRACK] of SECTOR; 
DISK = array [0. . (TRACKSperDISK-1) ] of TRACK; 

NOTE: Here you should be using the 
convention that track numbers are zero-based 
but sector numbers start from one. 

You can convert the type DISK into a linear 
arra ,T of c ECTOR as follows; 

type 

DISK = array [0. . (TRACKSperDISK*SECTORSperTRACK)-l] of SECTOR; 

You can use this linear representation for 
addressing the disk by PSN. The relations 
between the PSN, and track and sector 
numbers are: 



PSN = (TRACKNUKBER*SECTORSperTRACK) + SECTORNUMBER-1 ; 
TRACKNUMBER = PSN div SECTORSperTRACK; 
SECTORNUMBER = (PSN mod SECTORSperTRACK) + 1; 
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Physical Sector Size 

Any physical sector size may be accommodated. 
An I/O request in physical sector mode simply 
causes a full sector to be transferred. The 
programmer is responsible for ensuring that the 
data area is at least large enough for one 
physical sector. 

Programs written using physical sector mode 
aren't expected to be portable to different disk 
hardware without some modification. 
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THE RSP 

This section details the design and operation of the 
Input/Output portion of the Run- Time Support 
Package (RSP/IO). While the design itself is 
processor- and hardware-independent, it is intended 
to be realized in native code. Thus, the final 
product will be processor-specific but still 
independent of the exact peripherals used. 



Calling Mechanisms 

The following section discusses how each routine 
in the RSP/IO is called from the Pascal level (or 
the level of another compiled language). The 
level of detail is intended to be such that an 
implementor of the RSP will know how to pop 
parameters off the staek when the RSP is called, 
and how the stack should look when the RSP 
returns. 
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UNITREAD and UNITWRITE 



PROCEDURE UNITREAD ( UNITNUHBER : INTEGER; 

VAR DATAAREA : PACKED ARRAY [0. .BYTESTOTRANSFER-1] 
OF 0..255' 
BYTESTOTRANSFER : INTEGER 
[; LOGICALBLOCK : INTEGER] 
[; CONTROL : INTEGER] ) ; 

PROCEDURE UNITWRITE ( <same as for UNITREAD> ); 



Parameter Description 

UNITNUMBER was discussed under "Devices 
and Device Numbers" above. 
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DATAAREA is the programmer's buffer area 
for transferring data. Describing it as a VAR 
parameter signifies that UNITREAD and 
UNITWRITE are passed a pointer to the start 
of the data area. This pointer is actually 
represented as an address couple consisting of 
a word base and a byte offset. On processors 
which use byte addressing, the effective 
address is computed by simply adding the base 
and the offset, since both quantities are in 
bytes. For processors using word addressing, 
the effective address is computed by indexing 
byte-wise from the base address (always toward 
higher locations). Generally, the address of 
the start of the data area may or may not be 
on a word boundary. In the case of disk units, 
however, it is only defined if it is on a word 
boundary; that is, a Pascal programmer must 
not allow actual parameters with odd numbered 
indexes (like A[3]) to occur when transferring 
to or from the disk. The reason for this 
inconsistency is to avoid restricting disk data 
to being moved byte by byte. 

The third item in the parameter list, 
BYTESTOTRANSFER, contains the number of 
bytes to move between your data area and the 
physical unit. 

Two optional parameters follow for UNITREAD 
and UNITWRITE: LOGICALBLOCK and 

CONTROL. These parameters are optional for 
the Pascal programmer; the compiler will assign 
a default value of zero to both 
LOGICALBLOCK is relevant only for disk reads 
or writes, as discussed in "Logical Disk 
Structure," above. It specifies the Pascal 
logical block to be accessed. The CONTROL 
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word has been discussed above in "Control 
Parameters." 



Parameter Stack Format 

UNITREAD and UNITWRITE receive their 
parameters on the evaluation stack in the 
following order (each box represents a 16-bit 
quantity): 



/////////////// 



Unit 


Number 


Word Base 


Byte 


Offset 


Byte 


Count 


Block 


Number 


Control 



(on return, SP 
points here) 



(The stack shown here 
grows down) 
< sp 



Figure 4-6. Stack State on Entering 
UNITREAD or UNITWRITE 



Like ordinary Pascal procedures, these RSP 
routines pop their parameters from the stack 
when they are finished. 
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UNITBUSY 

FUNCTION UNITBUSY ( UNITNUMBER : INTEGER ) : BOOLEAN 

The UNITBUSY function has meaning only in an 
asynchronous environment and thus will always 
return FALSE (0) for this synchronous 
specification. The use of the stack is 

illustrated in Figure 4-7. 



////////////////// 

Function Result 
Unit Number 
before 



/////////////// 

False 



Figure 4-7. Stack State Before 
and After UNITBUSY 
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UNITWAIT 



PROCEDURE UNITWAIT ( UNITNUMBER : INTEGER ) ; 



Like UNITBUSY, UNITWAIT is only useful in an 
asynchronous environment. In a synchronous 
system, as described here, UNITWAIT becomes 
essentially a no-op, since no unit will have a 
I/O request pending. A single parameter is on 
the top of stack when the procedure is called 
and is popped off before the procedure returns. 
The use of the stack is illustrated in Figure 
4-8. 



++++ I/////////////// I SF M///////////////I 

| | , , 

I Unit Number l< SP I <empty> I 

before after 



Figure 4-8. Stack State Before and After 
UNITWAIT and UNITCLEAR 
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UNITCLEAR 



PROCEDURE UNITCLEAR ( UNITNUMBER : INTEGER ); 



The purpose of UNITCLEAR is to restore the 
specified device to its "initial" state. At the 
RSP level, this means clearing any state flags 
pertaining to the specified device. The 

"initial" state for each device at the BIOS 
level is defined in the section, "BIOS 
Responsibilities," below. The stack format is 
identical to that of UNITWAIT (see Figure 4-8 
above). 



UNITSTATUS 



PROCEDURE UNITSTATUS ( UNITNUMBER : INTEGER; 

VAR STATUSWORDS : ARRAY [C..29] OF INTEGER; 
CONTROL : INTEGER ) ; 



The purpose of UNITSTATUS is to acquire 
various device-dependent information from the 
specified UNIT. The procedure is passed a 
pointer to a status record (whose length is a 
maximum of 30 words) into which the status 
words are sequentially stored (note that users 
may define words starting at word 29 and 
allocating toward word 0, to allow for the 
system's use of the first words of the record) 
and a CONTROL word. 
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UNITSTATUS receives its parameters on the 
evaluation stack in the following order (each 
box represents a 16-bit quantity):" 



1/////////////// 


<— 


(on return, SP 

points here) 

(The stack shown here 
grows down) 


1 Unit Number 

1 Status 
1 Record 
1 Pointer 


1 Control 


„ 







Figure 4-9. Stack State Before 
and After UNITSTATUS 



RSP Responsibilities 

This section details the processing to be 
performed by the RSP/IO. The primary function 
of the RSP/IO is to manage calls to the BIOS. 
Secondarily, the RSP/IO is responsible for 
handling certain special functions, which are 
described here. 



Special Character Output Handling 

Output to the printer, console, remote, or 
serial units must properly handle blank 
compression codes and carriage returns. 
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Blank Compression Code (DLE's) 

The system supports text files that contain a 
two-byte blank compression code (only at the 
beginning of a line). It is the responsibility 
of the RSP/IO to decode the blank 
compression code and send an appropriate 
number of blanks. The first byte is an 
ASCII DLE (decimal 16), which signals that 
the next byte contains the excess-32 number 
of blanks to insert (that is, it should be 
interpreted as being the <number of blanks 
to be sent>+32). Therefore, the next byte 
following the DLE should be processed by 
subtracting 32 from its value and sending 
that number of blanks. Note that negative 
results, obviously in error, are translated to 
a value of zero. Also note that the 

blank-count byte may not be the next input 
byte processed, because of device switching. 
This, therefore, requires the maintenance of 
a flag for each device to indicate that it is 

i^nrpontl™ ruv-»f»*»ssincr fl T)T.T?. The DLE 
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character and the blank-count byte aren't 
normally sent to the device (see the 
paragraph, "NOSPEC Bit," below). 



Carriage Return — Line Feed 

Text files contain ASCII CR's (decimal 13) at 
the end of lines. We define this character 
as meaning "New Line"; that is, a carriage 
return followed by a line feed. Thus, it is 
the responsibility of the RSP/IO to send an 
ASCII LF (decimal 10) after sending each 
CR. 
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NOCRLF Bit 

When bit 3 (value 8) of the CONTROL 
parameter is set, the special handling 
accorded a CR is turned off; that is, a LF 
isn't automatically appended, and the CR is 
sent out like another character. 



Special Character Input Handling 

There are several characters which should 
receive special treatment when received from 
the console, the printer, the remote or the 
serial devices, in a complete implementation of 
this I/O system. All but two of them, 

however, are handled by the BIOS, Those 
which are handled in the RSP/IO are the EOF 
and ALPHALOCK characters. 
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EOF Character 

The EOF character, when received from the 
console, printer or remote devices, signals 
that the end-of-the-file has been reached on 
that particular unit. Rather than being a 
fixed ASCII code, EOF is a "soft character." 
That is, the exact character code which will 
be interpreted as end-of-file may be changed 
during system execution by the Paseal user. 
Further discussion of the soft characters 
used by the I/O subsystem may be found in 
the seetion, "Character Codes," below. The 
EOF character is in the SYSCOM data area 
and must be accessed by the RSP/IO to 
determine what character to look for. When 
the EOF character is found in the input 
stream, the action to be taken depends 
somewhat upon which device was referenced. 
If you are reading from UNIT 1 (CONSOLE:), 
then the rest of your buffer, starting at the 
current position, is packed with nulls 
(decimal 0), For UNIT 2 (SYSTERM;). the 
printer and the remote, the EOF character is 
put into your buffer. In all cases, no 
further characters are transferred to the 
buffer and control returns immediately. 
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ALPHALOCK Character 

The ALPHALOCK character, when received 
from a device by the RSP/IO, signals a 
default case change for all alphabetic 
characters. All lowercase alphabetic 

characters (that is, 'a' to 'z') received after 
the ALPHALOCK character will be converted 
to uppercase. Receipt of another 

ALPHALOCK character will cause the case 
to revert back to nonconverting mode (the 
default mode). As for DLE handling 

described above, a flag, for each device to 
indicate that it is currently in the 
ALPHALOCK state, should be maintained to 
ensure proper handling when devices are 
switched. The ALPHALOCK character is not 
normally returned in the buffer (see the 
paragraph, "NOSPEC Bit" below). 



Other Characters 

The remaining special input 
characters— BREAK, START/STOP, FLUSH, 
and CHARMASK— are used only for input 
from the console, not from the printer or 
remote devices. They are handled by the 
BIOS and are described under "Input 
Options," below. 
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NOSPEC Bit 

When bit 2 (value 4) of the CONTROL 
parameter is set, the special handling accorded 
DLE's, and the EOF and ALPHALOCK sensing 
functions described above are turned off. 
These characters are then transferred as are 
any other characters. The BIOS functions 
aren't affected. 



Translation for Subsidiary Volumes 

The RSP is also responsible for converting disk 
read/write calls to subsidiary volumes into disk 
calls for accessing the physical disk drive 
(instead of the virtual subsidiary volume). 

The SYSCOM area contains a pointer to the 
unitable which contains a record for each 
p-System unit. Each record for storage devices 

nnnttiinc o K1r»nb- r\ffcc*t onr« a rkVi\7cir»ol Hicl^ unit 

number. The RSP must look up calls to 
subsidiary volumes and give the physcial disk 
number and correct block number when the call 
to the BIOS is made. 
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The subsidiary volume requires some special 
checking in the RSP. The following Pascal 
code fragment describes how the RSP handles 
subsidiary volumes. 



if unit* in [syscom".subsidstart. . 

syscom'.subsidstart + syscom'.unitdivision.subsidmax -1] 
then {translate svol parameters) 

with sysconT.unitable'tunit*] do 
begin 

if ueovblk-0 then return_ioresult( 9 ) j 
if blockf >= ueovblk then return_ioresult ( 17 ); 
block* := block* + ublkoff; 
unit* := uphysvol; 
end 
else {no translation for other volumes needed}; 
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BIOS 



As explained above, the BIOS is responsible for 
providing the actual access to I/O devices. Both 
the design and implementation of the BIOS are 
specific to a given processor and I/O configuration. 
In this section, we will attempt to specify the 
nature of the BIOS in detai] sufficient for an 
experienced programmer to write the code for a 
given processor and a set of peripherals. 

The general scheme discussed below uses vectors 
from the RSP/IO to the BIOS subroutines for 
reading, writing, initializing and controlling, and 
answering status requests. The exact vector 

scheme and means of passing parameters must be 
worked out separately for each processor. 
Arrangements that have already been worked out 
for certain processors are illustrated in 
"Processor-Specific BIOS Calls," below. 



A/coign uvaio 



The speed at which BIOS code executes is fairly 
insignificant compared to the (slow) speed of the 
I/O devices that it handles. When peripherals are 
changed, which may occur frequently, it often 
proves that only minor changes need to be made 
to an existing BIOS to service the new hardware. 
Also, since the BIOS always resides in main 
memory, each byte it occupies means one byte 
less is available to the programmer. For these 
reasons, we suggest that major design goals 
(assuming correctness!) be: (1) compactness; and 
(2) clarity. 
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Like the rest of the PME, the BIOS should be 
ROM-able. Obviously, it will also require access 
to some RAM. The addresses that the BIOS 
references should be specified in the assembly 
code by equates, so that it is a simple matter to 
change them and reassemble the BIOS whenever 
there is a change in the I/O ports or the memory 
configuration. 



Completion Codes 

All read, write, initialization and control, and 
status calls to the BIOS must return a byte to 
the RSP that contains status information about 
the I/O request just serviced. The value of this 
byte is the "completion code" discussed in the 
section, "IORESULT and Completion Codes," 
above. Most of the standard completion codes 
aren't relevant to the BIOS— they are returned by 
the operating system for file errors and the like. 
The following standard errors can be returned by 
the BIOS: 



wo error 

1 CRC error 

2 Illegal device number 

3 Illegal operation on device 

4 Undefined hardware error 
9 Device not on line 

15 Ring buffer overflow 

16 Write protect; write attempt to protected disk 

17 Illegal block number 

18 Illegal buffer address 



All other errors are considered 
hardware-dependent. For these, the BIOS should 
return codes in the range 128 through 255. The 
selection of appropriate codes is left to the BIOS 
writer. 
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NOTE: Any predefined devices not implemented 
must arrange to return a completion code of 9 
("device not on-line") when an attempt is made to 
initialize or use them. 

Any user-defined devices not implemented should 
return a completion code of 2 ("illegal device 
number") when an attempt is made to access 
them. 



Calling Mechanisms 

In this section, we discuss the parameters 
required in the BIOS calls for each device. Each 
device has four BIOS calls associated with it: 
READ, WRITE, CONTROL, and STATUS. Each 
device has varying needs for information 
associated with these functions. Remember that 
all calls must return a completion-code byte. 
The BIOS calling requirements are summarized 
below. 



Console 

Only one parameter is needed for reading and 
writing— the data byte to be transferred. The 
status request requires two parameters: the 
CONTROL word and the pointer to the status 
record. For initialization and control of the 
console, the BIOS requires a number of special 
control characters. These are provided by 
passing the BIOS console initialization routine a 
pointer to the base of the SYSCOM data area, 
and a pointer to a break-handler routine. 



4-34 0400101:04A 



Low-Level I/O 



Printer 

To read from and write to the printer, a single 
parameter is required— the byte that contains 
the data. To check the status, the CONTROL 
word and the pointer to the status record are 
required. For initialization and control, no 
parameters are needed. 



Disks 

Reading and writing with disk devices requires 
five parameters: 

1. A starting logical block number as described 
above. 

2. A count of the number of bytes to transfer 
(positive signed 16 bits; that is, to 32K-1). 

3. The address of the data area to transfer to 
or from. 
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drives. Currently n=6 is assumed). 
5. The CONTROL parameter. 

To check the status, the CONTROL word and 
a pointer to the status record are passed as 
parameters. For initialization and control, the 
drive number is passed. 
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Remote 



The remote device requires a single parameter 
for reading and writing— a byte that contains 
the data being transferred. As with the 
devices just described, the status requires the 
CONTROL word and the pointer to the status 
record. Initialization and control of the 

remote device requires no parameters. 



User-Defined Devices 

Reading and writing with a user-defined device 
requires five parameters: 

1. A starting logical block number as described 
above. 

2. A count of the number of bytes to transfer 
(positive signed 16 bits, that is, to 32K-1). 

3. Tne address of the data area to transfer to 
or from. 

4. A device number (this will be the same as 
UNITNUMBER). 

5. The CONTROL parameter. 

The native code in the BIOS may choose to 
ignore some of this information, of course. 
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When checking status, the CONTROL word, 
device number, and a pointer to the status 
record are passed. For initialization and 
control, the device number is passed. It is left 
to the device handler to determine the specific 
device from its deviee number. 



Character Codes 

The system assumes that the printer and console 
devices will support the use of printable ASCII 
characters and a few standard control codes (CR, 
LF, SP, NUL and BEL). The remaining control 
codes that may be useful (such as cursor 
positioning and screen erasure) are "soft" 
characters that may be changed by the user 
(using the utility SETUP) to meet the 
requirements of some particular hardware. 



These soft characters, along with all other 
information that is entered using SETUP, are 
stored in the file *SYSTEM.MISCINFO. 
SYSTEM.MISCINFO is read into a portion of the 

booted or reinitialized. 
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The reason for keeping this hardware-dependent 
information at such a high level to be able to 
change a terminal (as happens fairly often) 
without creating a new BIOS. One way to do 
this is to map logical control symbols into control 
codes that are recognized by the hardware. 

Suppose, for example, that there is a predeclared 
procedure CURSORBACK which causes the cursor 
on a screen terminal to move left one column. 
Somewhere in the system, CURSORBACK must 
cause a control code to be sent to the terminal, 
which will cause the desired response; control-U, 
control-H, or an escape sequence. One way to 
do this would be for the compiler to emit a 
standard code which the BIOS then translates 
into whatever is correct for the current terminal. 
This has the disadvantage of requiring a new 
BIOS for every slightly different terminal. The 
approach which we have taken sees to it that 
the correct code is sent to the BIOS for the 
terminal that is currently on-line. 

Since many devices can make use of 8-bit control 
eodes, the system makes no assumptions about the 
relevance of the high-order bit, and transfers the 
whole byte unchanged. When using 7-bit ASCII, 
the value of the high-order bit is defined to be 
zero. This means that the BIOS must mask all 
characters from the console with the character 
mask in the SYSCOM, which is 127 (decimal) if 
7-bit ASCII is being used. 



4-38 0400101:04A 



Low-Level I/O 



The RSP sends both uppercase and lowercase 
characters to the BIOS. If a device can handle 
only uppercase characters, the BIOS must map 
lowercase into uppercase. 



BIOS Responsibilities 
Console 



In the following discussion, the console device 
is assumed to be a CRT terminal. 



Console Output Requirements 

As a minimum, every console device should 
provide the following keyboard functions: 

CR <carriage return> (hexadecimal 
OD) — Moves the cursor to the beginning 
of the current line (column 0). 

LF <line feed> (hexadecimal 0A) — Moves 
the cursor down one line while the column 
position remains the same. Starting from 
any but the last line on the screen, the 
contents of the screen should remain the 
same while the cursor moves downward. 
If the cursor is on the last line when the 
LF is issued, it should remain in the same 
position while the rest of the display 
scrolls upward one line and the bottom 
line clears. 
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BEL <bell> (hexadecimal 07) - If an 
audio signal is available, it will sound 
when the appropriate key is pressed. If 
one isn't available, the terminal will do 
nothing. 

SP <space> (hexadecimal 20) — Writes a 
space at the current cursor position 
(erasing whatever is there) and advance 
the cursor position by one column. If the 
cursor is already at the last position in a 
line, the position of the cursor after the 
SP is undefined. (We prefer that the 
cursor remain in its prior position in this 
case. If the cursor is in the last column 
of the last line on the screen, not only is 
the position of the cursor undefined after 
the SP, but so is the state of the 
screen— maybe it scrolled and maybe it 
didn't. We prefer that the cursor remain 
where it was and that the screen not 
scroll.) 

NUL <null> ( 00 ) - Causes a delay of 
the time required to write one character. 
The state of the console shouldn't change. 

Printable Characters (hexadecimal 21-7E) 
— Same as the discussion for SP, except, 
of course, write the character. 
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NOTE: The effect of sending nonprintable 
characters other than those described above 
isn't defined here since it varies from 
terminal to terminal. 



Console Output Options 

The following set of cursor and screen 
functions should be provided if possible. The 
control characters or sequences of characters 
that perform these functions are left 
unspecified (they are soft characters). If a 
stand-alone ASCII terminal is connected to 
the host system, these functions may be 
provided by the terminal itself. In this case, 
all the BIOS need do is pass the appropriate 

pnntrnl phnMntpps 



Eeverse Line Feed: Moves the cursor to 
the next line higher on the screen without 
changing the column or the contents of the 
screen. If the cursor is already on the top 
line, the result is undefined. If possible, the 
screen should revers o— s n r n ^ '" cn/»>> a mu-o 
or if that isn't feasible, the cursor and 
screen should just remain as they were. 



0400101:04A 4-41 



Low-Level I/O 



Non-Destructive Forward and Backward 
Space: Moves the cursor in the direction 
indicated without changing the contents of 
the screen (that is, moves it 
non-destructively). The position of the 

cursor is undefined if an attempt is made to 
move it beyond the beginning or the end of 
a line. The preferred result is that cursor 
and screen remain unchanged in such a case. 

Cursor HOME: Moves the cursor to the 
upper left-hand corner of the screen without 
changing the contents of the screen. 

Cursor X,Y Positioning: Moves the cursor 
to some absolutely determined row and 
column without disturbing the contents of the 
screen. The result is undefined if an 

attempt is made to move the cursor to a 
nonexistent position. 

f rase to ^nd of ^crssns Erases from the 
cursor position to the end of the screen, 
leaving the cursor where it started and the 
other contents of the screen undisturbed. 

Erase to End of Line: Erases from the 
cursor position to the end of the current 
line, leaving the cursor where it started and 
the rest of the screen undisturbed. 
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Console Input Requirements 

Input from the console should not be echoed 
to the screen by the BIOS; this function is 
handled by RSP/IO. Keys which represent 
ASCII characters should generate 8-bit codes 
between and 127. Other (non-ASCII, that 
is, special function) keys can generate codes 
between 128 and 255, if desired. 



Console Input Options 

If possible, we recommend that the console 
input BIOS be responsible for the following 
special functions. 
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START/STOP 

The START/STOP character is used to 
control console output. When START/STOP 
(a soft character) is received, console output 
is suspended until: (1) another START/STOP 
character is received; (2) a FLUSH character 
is received; (3) the console BIOS is 
reinitialized; or (4) the BREAK character is 
received. The action to take in the last 
three cases is discussed below. Should 

another START/STOP character be received, 
the suspended activities should resume 
exactly as they left off. The chief benefit 
of this arrangement is that you can suspend 
output processes which are proceeding too 
fast (for example, a text file scrolling across 
the screen at 9600 baud). The suspension 
process takes place wholly within the BIOS, 
and requires no communication to the RSP. 
(Note that the START/STOP character is 
never returned to the RSP. The queueing of 
keyboard inr»ut- if implemented- should 
continue during the suspension.) 
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FLUSH 

FLUSH is another soft control character. 
When FLUSH is typed, the console output 
BIOS discards all output characters (that is, 
doesn't display them) until: (1) FLUSH is 
entered again; (2) input is requested from the 
console BIOS; (3) the console BIOS is 
reinitialized; or (4) the BREAK character is 
received. The FLUSH character is never 
returned to the RSP. If FLUSH is received 
while a START/STOP suspension is pending, 
the suspension is canceled and FLUSH has its 
usual effect. This feature is useful when a 
long text file is being displayed on the 
console and you're tired of looking at it. If 
you push FLUSH, it terminates rather 

mCivLjr. J.L io aiau uoeiili wiicn ti yruCCss is 

generating console output that is irrelevant, 
but slows down the process. Note that 
FLUSH applies only to console output. 
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BREAK 



When BREAK (also a soft character) is 
entered, the console input BIOS should check 
the state of the NOBREAK flag bit in the 
SYSCOM data area. If the NOBREAK flag 
is a 1, then the BREAK key should be 
ignored (the console input routine should go 
back to waiting for a character from the 
console). If the NOBREAK flag is a 0, then 
the BIOS should immediately give control to 
a special PME routine. The vector to this 
routine is passed at console initialization 
time. After execution of the BREAK 

routine, the BIOS should continue as before. 
The BREAK routine is responsible for 
notifying the PME that a BREAK should be 
executed before the next p-code is 
interpreted. (Note that the BREAK 

character is never returned to the RSP. 
Receipt of BREAK should terminate any 
START/STOP or FLUSH suspension pending.) 

The system stores the NOBREAK boolean in 
the data area called SYSCOM. A pointer to 
SYSCOM is passed to the console 
initialization routine. The byte containing 
the NOBREAK boolean must be masked with 
01000000 binary (40 hexadecimal) before 
examining the NOBREAK boolean, the other 
bits aren't necessarily zero. 
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Type- Ahead 

When nonspeeial characters (ones not 
described in the sections above) are received 
from the keyboard, and when a no read 
request is pending, they should be queued 
until the next read request. The next read 
request should remove the first character 
from the queue. When characters in excess 
of the maximum queue size are received, 
they should be ignored; the queue should 
remain intact. While a type-ahead of even 1 
character is better than none at all, we 
recommend a minimum queue size of about 20 
characters. If possible, the bell should be 
sounded for each character entered from the 
keyboard after no room remains in the queue. 



Input Character Mask 

In the p-System, prior to version IV. 1, all 
characters input from the console were 
masked with 7F (hexadecimal) to clear the 
Daritv bit in bit 7. This ehane-ed. in version 
IV. 1, to allow terminals (or keyboards) that 
use full 8-bit character codes to return them 
unmasked, and to continue to allow terminals 
that needed to have the parity bit cleared to 
work. 
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Every character read from the console should 
be ANDed with the CHAR_MASK byte found 
in the SYSCOM data area. This will be set 
with the SETUP utility to be either 7F or 
FF (hexadecimal) as needed. The masking 
should be done before checking for BREAK, 
START/STOP or FLUSH. 



Initialization and Control 

The initialization and control part of the 
console BIOS is responsible for the following 
tasks (and whatever else the BIOS implementor 
finds expedient): 
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SYSCOM Data Area: The system stores soft 
characters: START/STOP, FLUSH, BREAK and 
other special variables in the SYSCOM data 
area. These are variables that must be 

accessible from both the operating system and 
the low-level routines (PME, RSP, and BIOS). 
One parameter to the console initialization and 
control routine is a pointer to the start of the 
SYSCOM area. The SYSCOM is a packed 
record declared in the interface section of the 
unit KERNEL. Byte offsets within SYSCOM 
depend on the processor sex (low-byte or 
high-byte first). The offsets to variables used 
in the BIOS and RSP are (expressed as positive 
byte offsets): 



LSB first (decimal) MSB first (decimal) 

decimal hex octal decimal hex octal Usage 



FLUSH 


83 


53 


123 


82 


52 


122 


BIOS 


BREAK 


84 


54 


124 


85 


55 


125 


BIOS 


STOP/START - 


85 


55 


125 


84 


54 


124 


BIOS 


CHARMASK 


92 


5C 


134 


93 


5D 


135 


BIOS 


NOBREAK 


58 


3A 


72 


59 


3B 


73 


BIOS 


EOF 


82 


53 


122 


83 


53 


123 


RSP 


ALPHALOCK - 


93 


5D 


135 


92 


5C 


134 


RSP 



BREAK Vector: Another initialization and 
control parameter is the address of the PME 
routine which handles BREAK. The console 
initialization code is responsible for setting up 
a vector to this address via its private data 
area and calling this routine when the BREAK 
character is received. 
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Flags: Initialization should cause the 
START/STOP and FLUSH flags to be cleared 
(or whatever else may be required to return to 
normal). 

Type-Ahead Queue: Initialization should cause 
any characters currently waiting in the 
type-ahead queue to be discarded. 



Console Status 

As described in "Control Parameters," at the 
beginning of this chapter, bit (value 1) of 
the CONTROL word defines the direction of 
the status request. The request should 

return, in the first word of the status 
record, the number of characters currently 
queued for the direction specified. If some 
form of buffering is being used, this will 
simply be the number of characters in the 
buffer. If no buffering is implemented, the 

^..4. j. _.*._* ...:n »i. H «4-. ..*•*. n k,.4- +v*« 
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input status will return 1 if a character is 
waiting to be read, or if none is waiting. 



Printer 

The printer is expected to be a line printer or 
other hard copy device. In actual practice, 
any ASCII display device may be used. 
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Printer Output Requirements 

In order to serve the widest variety of hard 
copy devices, the RSP/IO doesn't buffer a 
line of text and send it all at once. Rather, 
it sends the printer BIOS a single character 
at a time. Many line printers must buffer a 
line and then print it all at once; if this is 
the case, it is the BIOS that must do so, in 
which case, the BIOS must recognize the end 
of a line (EOLN). EOLN is signalled by a 
certain character; the possibilities are listed 
below: 

CR <carriage return> (hexadecimal OD) — 
Print the line and return the carriage to the 
first column. An automatic line feed should 
not be done. 

LF <line feed> (hexadecimal OA) — In 
normal operation, the RSP/IO will only send 
an LF to the BIOS immediately after a CR. 
If the hardware allows a simple line feed to 
be performed (without a return), then this 
should be done. If a complete "new line" 
operation (that is, return and line feed) is 
the only way your printer can print a line, 
then do so at an LF— don't do anything about 
a CR. 
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FF <form feed> (hexadecimal OC) - The 
printer should advance the paper to 
top-of-form, if possible, and perform a 
carriage return. If no such feature is 
available, the printer may execute a "new 
line" operation; that is, a return followed by 
a line feed. 



Printer Input Requirements 

There are no strict requirements for input 
from the printer device. If the printer 
device has the capability to transmit data, 
then the printer input BIOS should return all 
eight data bits unchanged. If not, then input 
shouldn't be allowed and should return 
completion code 3 ("illegal operation on 
device"). 



Printer Initialization and Control 

Initialization of the printer device should 
make it ready to print at the beginning of a 
blank line. A "new line" (carriage return 
and line feed) operation may be in order 
here. Any characters that have been 

buffered but not printed are lost. The 
printer doesn't need to do a form feed each 
time it is initialized. 
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Printer Status 

As described above, the number of characters 
buffered for the direction specified in the 
CONTROL word should be returned in the 
first status word. If the printer has no form 
of self-checking, return 0. 

When returning output channel status the 
number of characters buffered has a special 
meaning. A zero returned (for number of 
characters buffered) means the printer is 
ready to receive a character, a non-zero 
value in interpreted as meaning the printer 
isn't ready to receive another character. 
The print spooler uses this to determine if it 
can send a character to the printer without 
hanging the system (in the background task) 
on a write to the printer. 



Disk 



Ma nni ner Rl rt/»lre r\n PhticiAQ 1 GaaIavc 



The disk device may be any type of disk 
drive (for example, floppy or hard disk). The 
actual sectoring arrangements of the disk are 
immaterial. The system addresses the disk in 
terms of consecutive logical blocks of 512 
bytes each. A primary function of the disk 
BIOS, therefore, is to provide an appropriate 
mapping scheme into the actual (physical) 
sectors used on the disk. The sector 

interleaving algorithm should be optimal for 
the hardware. 
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The system makes no assumptions about the 
interleaving method used by the BIOS (except 
that it works!). 



Bootstrap Location 

While bootstrap schemes vary, typical 
implementations make use of a hardware 
(usually ROM) bootstrap to load and execute 
a primary software bootstrap which, in turn, 
loads and executes a secondary software 
bootstrap. The secondary bootstrap then 
loads the PME and operating system, 
performs required initializations, and starts 
the system. 

To be accessible to the hardware bootstrap, 
the primary software bootstrap must reside 
at a location on the disk which is 
predetermined by the hardware vendor. 
Since these locations can vary widely, it is 
necessary that the system's requirements for 
a physical disk format be flexible in this 
regard. 

The primary bootstrap area must not overlap 
disk data structures maintained by the system 
(chiefly the directory and the bootstrap 
itself). 

Logical blocks and 1 of each disk are 
usually reserved for bootstrap code (a total 
of 1024 bytes). This is the most convenient 
alternative. 
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If 1024 bytes aren't enough room, or if the 
interleaving format is unacceptable to the 
hardware bootstrap, the primary bootstrap 
area must be outside of the "Pascal disk." 
The Pascal logical blocks must be mapped 
onto the disk in such a way that the 
hardware-defined bootstrap area is 
inaccessible to the p-System as a logical 
block. (It will still be accessible in Physical 
Sector Mode, see above.) 

For adaptable systems, full details about 
bootstrap locations and the mechanisms of 
booting may be found in the Adaptable 
System Installation Manual . 



Physical Sector Mode 

When bit 1 (value 2) of the CONTROL word 
is set, disk access should be performed in 
Physical Sector Mode, as described in the 
section, "Physical Sector Addressing Mode," 
above. 
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Disk Output Requirements 

The disk device BIOS must transfer as many 
actual sectors as are needed to accommodate 
the data. To simplify a disk-write in which 
(BYTESTOTRANSFER) MOD 512 isn't equal 
to zero (for example, a block is partially 
written to), the remaining contents of the 
last block are undefined . This makes it 
possible to write as much of whatever 
garbage remains in the buffer; if that is 
most convenient, to fill up a whole sector. 
Figure 4-10 illustrates this situation. The 
language level is responsible for keeping 
track (in logical block numbers and byte 
counts) of where the good data is. 

EXAMPLE: 

Write to disk. 

Number of bytes to transfer = 1174 
Starting logical block number = 72 
Data area address = DATAABEA 

! I : 

Block 72 I Block 73 I Block 74 
(512 bytes) I (512 bytes) I 150 :(362 bytes) 
I I bytes: 

data >:<undef ined> 

I I : 



I I 

start of data area end of data area 

end of last block 



Figure 4-10. State of Blocks on Disk 
After Being Written 
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Disk Input Requirements 

On input from a disk device, it's not 
permissible to over-write the end of the 
assigned data area. Therefore, the BIOS is 
responsible for transferring no more than the 
number of bytes requested. One way to 
accomplish this is to buffer the last sector 
and then transfer only the requested part. 



Disk Initialization and Control 

Initialization of a disk device should bring it 
to a state in which it is ready to read or 
write from any given track or sector. For 
some drives with simple controllers, the head 
may need to be stepped to track to 
facilitate the BIOS disk driver's remembering 
the current track. Any buffered data is 
lost. 

Disk Status 



Status requests from the disk will return the 
following words in the status record: 

Word 1 — The number of bytes currently 
buffered for the direction specified in the 
CONTROL word, as described in the 
section, "Console Status," above. If no 
capability for checking is available, it 
should be set to 0. 



0400101:04A 4-57 



Low-Level I/O 



Word 2 — The number of bytes per sector. 

Word 3 — The number of sectors per 
track. 

Word 4 — The number of tracks per disk. 



Remote 

This unit is intended to be an RS-232 serial 
line for supporting various types of 
communication. It is important that it transfer 
raw data without changing it in any way. All 
eight bits of the transferred byte should be 
considered significant. The transfer rate is 
usually set to 9600 baud. 



Remote Output Requirements 

As noted above, all 8-bits of the data byte 
should be transmitted. The remote BIOS 
driver is sent one byte at a time. 

Remote Input Requirements 

Input from a remote device should be 
buffered, if possible, by the scheme 
suggested in "Type-Ahead" section. As noted 
above, all eight data bits must be returned. 
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Remote Initialization and Control 

Initialization of the remote device should 
bring it to a state in which it is ready to 
read or write. 

Remote Status 

The number of bytes buffered for the 
direction specified in the CONTROL word 
should be returned in the first status word, 
as described in the "Console Status" section, 
above. If no capability for checking is 
available, it should return 0. 

User-Defined Devices 

These devices are intended to allow you the 
freedom to implement devices not specifically 
defined in this document. The actual 

implementation is left entirely to you. The 
only requirement is that they return a 
completion code when finished and, if the 
UNITNUMBER isn't defined, that it return code 
2 ("illegal unit number"). You should use 
device numbers starting from 128 (see 
"User-Defined Devices," above). 
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Special BIOS Calls 

These functions are provided by the BIOS to 
make configuration-specific functions accessible 
to the PME. Although these functions aren't 
related to I/O, they are put into the BIOS as the 
repository for configuration-specific code. 

As with all other routines in the BIOS, each 
should return a completion code. 



System Output 

System Output is reserved for future expansion 
and, at this time, should cause the system to 
HALT. (Note that HALT may actually cause a 
reboot on some (few) implementations.) 



System Input 

System Input is also reserved for future use, 
and like System Output, should cause a HALT. 



System Initialization and Control 

The System Initialization and Control BIOS 
routine should initialize such things as the 
clock (reset it to 0) and the interrupt system, 
if either is to be used. 



4-60 0400101:04A 



Low-Level I/O 



System Status 

The System Status BIOS routine should return 
the following information in the status record: 

Word 1 — The address of the last word in 
accessible contiguous RAM memory; for 
example, on an 8080 system with 64K bytes 
of RAM, the last byte address may be 
'FFFF', but the last word address is 'FFFE'. 

Word 2 — The least significant part of the 
32-bit word used by the system clock. If a 
clock isn't present, then this must be set to 
0. 

Word 3 — The most significant part of the 
32-bit word used by the system clock. If a 
clock isn't present, then this must be set to 
0. 

NOTE: If a clock is used, the system assumes 

that the tWfl W/Or*<lR l"*»tllT»n<=>H ava t-nr«>aoantotitr/> 
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of the time in 60ths of a second. It is the 
clock driver's responsibility to maintain the 
closest approximation to this time. The time is 
defined to be at clock initialization. 
Currently, the CONTROL word is ignored. 
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BIOS CALLING CONVENTIONS 

The following is a summary of the calling 
conventions described earlier. The 

processor-specific protocols for certain machines 
are shown in the following section. All calls to 
the BIOS return a completion code. 



Entry Point 

CONSOLEREAD 

CONSOLEWRITE 

CONSOLECTRL 

CONSOLESTAT 

PRINTERREAD 
PRINTERWRITE 
PRINTERCTRL 
PRINTERSTAT 



Parameters 

single data byte 
single data byte 
BREAK vector 
SYSCOM pointer 
STATREC pointer 
CONTROL word 
single data byte 
single data byte 
(none) 

STATREC pointer 
CONTROL word 



Ul»R.JK.£.ii.lJ 



D1SKWRITE 

DISKCTRL 

DISKSTAT 



kl -I. »*.*v>K^n 

DJA-HJIV IIUIIIl/Ol 

byte count 
data area address 
drive number 
CONTROL word 
(same as DISKREAD) 
drive number 
drive number 
STATREC pointer 
CONTROL word 



REMOTEREAD 
REMOTE WRITE 
REMOTECTRL 



single data byte 
single data byte 
(none) 



4-62 



0400101:04A 



Low-Level I/O 



REMOTESTAT 


STATREC pointer 




CONTROL word 


USERREAD 


block number 




byte count 




data area address 




device number 




CONTROL word 


USERWRITE 


(same as USERREAD) 


USERCTRL 


device number 


USERSTAT 


device number 




STATREC pointer 




CONTROL word 


SYSREAD 


block number 




byte count 




data area address 




device number 




CONTROL word 


SYSWRITE 


(same as SYSREAD) 


SYSCTRL 


device number 




EVENT vector 


SYSSTAT 


STATREC pointer 




CONTROL word 


QUIET 


(none) 


ENABLE 


(none) 


SERREAD 


device number 




single data byte 


SERWRITE 


device number 




single data byte 


SERCTRL 


device number 


SERSTAT 


device number 




STATREC pointer 




CONTROL word 



0400101:04A 



4-63 



Low-Level I/O 



PROCESSOR-SPECIFIC BIOS CALLS 



8086/8088 

Entry Points: All BIOS entry points are given as 
positive offsets from the BIOS vector table. The 
location of this vector table is given by the label 
BIOSVC, which is defined with a .DEF in the 
BIOS. Each entry in the vector table should be 
a pointer to the routine that implements that 
BIOS function. The pointer is relative to be 
beginning of the PME. 

Parameters: When parameters aren't being passed 
in a specified register, they are pushed onto the 
stack. Offsets from the address pointed to by 
SP (indicated as (SP)) are given. (Remember that 
the stack grows down and that SP normally 
points at the last word pushed on the stack.) 

Completion Code: Return in register AH. 

Calling Sequence: The RSP will use the CALL 
BIOSVC(BX) (intrasegment, indirect) to call the 
routine within the BIOS. The BIOS routines may 
make free use of registers 

AX,BX,CX,DX,BP,SI,DI, with the exception of 
QUIET, ENABLE, and SYSTEMSTAT which may 
only use AX,BX,CX,DI. Registers CS,DS,SS,ES 
must be returned unchanged. 
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Entry Point 

CONSOLEREAD 

CONSGLEWRITE 

CONSOLECTRL 

CONSOLESTAT 



PRINTERREAD 
PRINTERWRITE 
PRINTESCTRL 
PRINTERSTAT 



Offset (hex) Parameters 



DISKWFITE 

DISKCTRL 

DISKSTAT 



REHOTEREAD 

REMOTEWRITE 

REMOTECTRI, 

REMOTESTAT 



USERWRITE 

USERCTRL 

(JSERSTAT 



SYSWRITE 
SYSCTRL 



QUIET 
ENABLE 



00 
02 
04 



06 



08 
0A 

oc 

0E 



10 



12 
14 
16 



18 
1A 
1C 

IE 



22 

24 
26 



28 



2A 
2C 



2E 



30 
32 



return data byte in AL 

write data byte in AL 

BREAK vector at (SP)+2, (SP)+3 

SYSCOM pointer at (SP)+4, (SP)+5 

STATREC pointer at (SPJ+2, (SP) +3 

CONTROL word at (SP)+4, (SP)+5 

return data byte in AL 

write data byte in AL 

(none) 

STATREC pointer at (SP)+2, (SP)+3 

CONTROL word at (SPJ+4, (SP) +5 

block number at (SP)+2, (SP)+3 

byte count at (SP)+4, (SPJ+5 

data area address at (SP1+6, (SP) +7 

drive number at (SPJ+8, (SP)+9 

CONTROL word at (SPJ+10, (SP>+11 

data area segment in ES 

(same as DISKREAD) 

drive number in CL 

drive number in CL 

STATREC pointer at (SP)+2, (SP) +3 

CONTROL word at (SP1+4, (SP)+5 

return data byte in AL 

write data byte in AL 

(none) 

STATREC pointer at (SP1+2, (SP)+3 

CONTROL word at (SP)+4, (SP)+5 

block number at (SP)+2, (SP)+3 

byte count at (SP)+4, (SP)+5 

data area address at (SP)+6, (SP)+7 

device number at (SPJ+8, (SP) +9 

CONTROL word at (SP)+10, (SPJ+11 

data area segment in ES 

(same as USERREAD) 

device number in CL 

device number in CL 

STATREC pointer in (SP)+2, (SPJ+3 

CONTROL word in (SPJ+4, (SPJ+5 

block number at (SPJ+2, (SPJ+3 

byte count at (SPJ+4, (SP)+5 

data area address at (SP1+6, (SP)+7 

drive number at (£P)+8, (SP)+9 

CONTROL word at (SP1+10, (SPJ+11 

data area segment in ES 

(same as SYSREAD) 

EVENT vector at (SP)+2, (SP)+3 

device number in CL 

device number in CL 

STATREC pointer in (SP)+2, (SP)+3 

CONTROL word in (SP)+4, (SP1+5 

(none) 
(none) 



SERIALREAD 



34 



return data byte in AL 
device number in CL 
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SERIALWRITE 36 write data byte in AL 

device number in CL 
SERIALCTRL 38 device number in CL 

SERIALSTAT 3A device number in CL 

STATREC pointer in (SP)+2, (SP)+3 
CONTROL word in (SP)+4, CSP) +5 
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8080/Z80 

Entry Points: All BIOS entry points are given as 
positive offsets from the beginning of the BIOS 
code space. These locations should contain a 
JMP instruction to the appropriate address in the 
BIOS. 

Parameters: When parameters aren't being passed 
in a specified register, they are pushed onto the 
stack. Offsets from top-of-stack are given (the 
stack grows down). 

Completion Code: Return in register A. 

Calling Sequence: The RSP will use the CALL 
instruction to call the BIOS. Thus the return 
address is at (SP),(SP)+1. All registers are 
available for use by the BIOS. The BIOS should 
clean off the stack before returning to the RSP. 



Entry Point 


Offset (h 


CONSOLEREAD 


00 


CONSOLEWRITE 


03 


CONSOLECTRL 


06 


CONSOLESTAT 


09 


PRINTERREAD 


OC 


PRINTERWRITE 


OF 


PRINTERCTRL 


12 


PRINTERSTAT 


15 


DISKREAD 


18 


DISKWRITE 


IB 


DISKCTRL 


IE 



return data byte in Req C 
write data byte in Reg C 
BREAK vector at (SP)+2, (SP) +3 
SYSCOH pointer at (SP) +4, (SP) +5 
STATREC pointer at (SP) +2, (SP) +3 
CONTROL word at (SP) +4, (SP) +5 

return data byte in Reg C 

write data byte in Reg C 

(none) 

STATREC pointer at (SP) +2 , (SP) +3 

CONTROL word at (SP) +4, (SP) +5 

block number at (SP) +2, (SP) +3 
byte count at (SP)+4, (SP) +5 
data area address at (SP)+6, (SPJ+7 
drive number at (SP) +8, (SP) +9 
CONTROL word at (SP) +A, (SP) +B 
(same as DISKREAD) 
drive number in Reg C 
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DISKSTAT 



21 drive number in Reg c 

STATREC pointer at (SP) +2, (SP) +3 
CONTROL word at (SP) +4, (SP)+5 



REMOTEREAD 
REMOTEWRITE 
REMOTECTRL 
REMOTESTAT 



24 return data byte in Reg C 
27 write data byte in Reg C 
2A (none) 

2D STATREC pointer at (SP)+2, (SP) +3 
CONTROL word at (SP) +4, (SP) +5 



USERWRITE 

USERCTRL 

USERSTAT 



30 



33 
36 
39 



block number at (SP)+2, (SP)+3 

byte count at (SP)+4, (SP)+5 

data area address at (SP) +6, (SP) +7 

device number at (SP) +8, (SP) +9 

CONTROL word at (SP) +A, (SP) +B 

(same as USERREAD) 

device number in Reg C 

device number in Reg C 

STATREC pointer at (SP) +2, (SP) +3 

CONTROL word at (SP) +4 , (SP) +5 



SYSWRITE 

SYSCTPL 

SYSSTAT 



3F 
42 

45 



block number at (SP) +2, (SP) +3 
byte count at (SP) +4, (SP) +5 
data area address at (SP) +6, (SP) +7 
device number at (SP) +8 , (SP) +9 
CONTROL word at (SP) +A, (SP) +B 
(same as SYSREAD) 
EVENT vectoi at (SPJ+2, (SP)+3 
STATREC pointer at (SP)+2, (SP)+3 
CONTROL word at (SP)+4, (SP1+5 



QUIET 
ENABLE 



48 

4B 



(none) 
(none) 



SERIALREAD 
SER1ALWRITE 



SERIALCTRL 
SEKiAlSTA'T 



4E return data byte in C 

device number at (SP)+2, (SP)+3 

51 write data byte in C 

device number at (SP)+2, (SP) +3 

54 device number at (SP)+2, (SP1+3 

57 device nuiubet at (SF)-»-2, (SP)-*-3 

STATREC pointer in (SPJ+4, (SP)+5 
CONTROL word in (SP)+6, (SP)+7 
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6502 

Entry Points: All BIOS entry points are given as 
positive offsets from the beginning of the BIOS 
code space. These locations should contain a 
JMP instruction to the appropriate address in 
BIOS. 

Parameters: When parameters aren't being passed 
in a specified register, they are pushed onto the 
stack. Offsets from the address pointed to by S 
(indicated by (S)) are given (the stack grows 
down; and that S normally points to the first 
available address below valid data). 

Completion Code: Return in register X. 

Calling Sequence: The RSP will use the JSR 
instruction to call the BIOS. Thus the return 
address is at (S)+l, (S)+2. All registers are 
available for use. The stack should be cleaned 
off by the BIOS before returning to the RSP. 



Entry Point 

CONSOLEREAD 
CONSOLEWRITE 

CONSOLECTRL 

CONSOLESTAT 



PRINTERREAD 
PRINTERWRITE 
PRINTERCTRL 
PRINTERSTAT 



Offset (hex) 

00 
03 
06 

09 



0C 
OF 
12 
15 



18 



Parameters 

return data byte in Reg A 
write data byte in Reg A 
BREAK vector at (S)+3,(S)+4 
SYSCOH pointer at (S)+5,(S)+6 
STATREC pointer at (S)+3,(S)+4 
CONTROL word at (S)+5,(S)+6 

return data byte in Reg A 
write data byte in Reg A 
(none) 

STATREC pointer at (S)+3,(S)+4 
CONTROL word at (S)+5,(S)+6 

block number at (S)+3,(Sl+4 
byte count at (S)+5,(s)+6 
data area address at (S)+7,(S)+8 
drive number at (S)+9,(s)+A 
CONTROL word at (S)+B,(S)+C 
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DISKWRITE 

DISKCTRL 

DISKSTAT 



IB (same as DISKREAD) 
IE drive number in Reg A 
21 drive number in Reg A 

STATREC pointer at (S)+3,(S)+4 
CONTROL word at (S)+5,(S)+6 



REMOTEREAD 
REMOTEWRITE 
REHOTECTRL 
REMOTESTAT 



24 return data byte in Reg A 
27 write data byte in Reg A 
2A (none) 

2D STATREC pointer at (S)+3,(S)+4 
CONTROL word at <S)+5,(S)+6 



USERWRITE 

DSERCTRL 

USERSTAT 



30 



33 
36 
39 



block number at (E)+3,(S)+4 
byte count at (S)+5,(S)+6 
data area address at (S)+7,(S)+8 
device number at (S)+9,(S)+A 
CONTROL word at (S)+B,(S)+C 
(same as USERREAD) 
device number in Reg A 
device number in Reg A 
STATREC pointer at (S)+3,(S)+4 
CONTROL word at (S)+5,(S)+6 



SYSREAD 



SYSWRITE 
SYSCTRL 



SYSSTAT 



3F 
42 



45 



block number at (S)+3,(S)+4 

byte count at (S)+5,(S)+6 

data area address at (S)+7,(S)+8 

device number at (S)+9,(S)+A 

CONTROL word at (S)+B,(S1+C 

(same as SYSREAD) 

device number in A 

EVENT vector at (S)+3, (S)+4 

device number in A 

STATREC pointer in (S)+3, (S)+4 

CONTROL word in (S)+5, (S)+6 



QUIET 
ENABLE 



SERIALREAD 
SERIALWRITE 



SERIALCTRL 
SERIALSTAT 



48 


(none) 




4B 


(none) 




4E 


return data byte 


in A 






V 








51 


write data byte 


in A 




device number in 


Y 


54 


device number in 


A 


57 


device number in 


A 



STATREC pointer in (S)+3, (S)+4 
CONTROL word in (S)+5, (S)+6 
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6809 



Entry Points: All BIOS entry points are given as 
positive offsets from the beginning of the BIOS 
code space. These locations should contain a 
vector to the appropriate address in the BIOS. 

Parameters: When parameters aren't being passed 
in a specified register, they are pushed onto the 
stack. Offsets from the address pointed to by 
SP (indicated by (SP)) are given (the stack grows 
down; and that SP normally points at the last 
item nushed on the stack). 



Completion Code: Return in register B. 

Calling Sequence: The RSP will use the JSR 
instruction to call the BIOS. Thus, the return 
address will be at (SP)+0, (SP)+1. The U and Y 
registers contain PME information which must be 
preserved/restored by the BIOS prior to returning 
to the RSP. All other registers are available for 
use. The stack should be cleaned off by the 
BIOS before returning to the RSP. 



Entry Point 


Offset (hex) 


Parameters 


CONSOLEREAD 




00 


return data byte in Reg A 


CONSOLEWRITE 




03 


write data byte in Reg A 


CONSOLECTRL 




06 


BREAK vector at (SP) +2 , (SP) +3 
SYSCOM pointer at (SP) +4, (SP) +5 


CONSOLESTAT 




09 


STATREC pointer at (SP)+2, (SP) +3 
CONTROL word at (SP) +4, (SP) +5 
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PRINTERREAD 
PRINTERWRITE 
PRINTERCTRL 
PRINTERSTAT 



DISKWRITE 

DISKCTRL 

DISKSTAT 



OC return data byte in Reg A 
OF write data byte in Reg A 
12 (none) 

15 STATREC pointer at (SP) +2 , (SP) +3 
CONTROL word at (SP)+4, (SP)+5 

18 block number at (SP)+2, (SPJ+3 
byte count at (SP)+4, (SP1+5 
data area address at (SP) +6, (SP! +7 
drive number at (SP)+8, (SP) +9 
CONTROL word at (SP)+A, (SP) +B 

IB (same as DISKREAD) 

IE drive number in Reg A 

21 drive number in Reg A 

STATREC pointer at (SP)+2, (SP)+3 
CONTROL word at (SP)+4, (SP) +5 



REMOTEREAD 
REMOTEWRITE 
REMOTECTRL 
REMOTESTAT 



USERREAD 



USERWRITE 

USERCTRL 

USERSTAT 



SYSREAD 



SYSCTRL 
SYSSTAT 



24 return data byte in Reg A 
27 write data byte in Reg A 
2A (none) 

2D STATREC pointer at (SP) +2, (SP)+3 
CONTROL word at (SP)+4, (SP)+5 

30 block number at (SP)+2, (SP) +3 
byte count at (SP) +4, (SP) +5 
data area address at (SP)+6, (SPJ+7 
device number at (SP1+8, (SP)+9 
CONTROL word at (SP)+A, (SP)+B 

33 (same as USERREAD) 

36 device number in Reg A 

39 device number in Reg A 

STATREC pointer at (SP) +2, (SP)+3 
CONTROL word at (SP)+4, (SP) +5 

3C block number at (SP)+2, (SP)+3 
byte count at (SP)+4, (SPJ+5 
data area address at (SP) +6, (SP) +7 
device number at (SP) +8, (SP! 1+9 
CONTROL word at (SP) +A, (SP) +B 

ji' \SoiT>e as ojoiMjni// 

42 device number in A 

EVENT vector at (SP)+2, (SP)+3 

45 device number in A 

STATREC pointer at (SPJ+2, (SP) +3 
CONTROL word at (SP)+4, (SP)+5 



QUIET 
ENABLE 



SERIALREAD 
SERIALWRITE 



SERIALCTRL 
SERIALSTAT 



48 
4B 



4E 
51 



54 
57 



(none) 
(none) 

return data byte in A 

device number at (SP)+2, (SP)+3 

write data byte in A 

device number at (SP)+2, (SP)+3 

device number at (SP)+2, (SP)+3 

device number at A 

STATREC pointer in (SPJ+2, (SP) +3 

CONTROL word in (SPJ+4, (SP)+5 
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68000 



Entry Points: All BIOS entry points are given as 
positive offsets from the BIOS jump table. The 
location of this jump table is given by the label 
BIOSVC which is defined with a .DEF in the 
BIOS. Each entry in the jump table should be a 
long BRAnch to the routine that implements that 
BIOS function. 



Parameters: In general, parameters are passed to 
the BIOS using the following register scheme: 



DO.B - character 


A0 - 


- free 


Dl.B - result code 


Al - 


- free 


D2.W - control 


A2 - 


- buffer address 


D3.W - block number 






D4.W - bytes 






D5.B - unit number 







Completion Code: Returned in register Dl.B. 

Calling Sequence: The RSP will use the JSR 
instruction to call into the jump table within the 
BIOS. The BIOS routines may make free use of 
registers DO,D1,AO,A1. No other registers 

(including the parameter registers) may be 
destroyed. 
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Entry Point 

CONSOLEREAD 

CONSOLEWRITE 
CONSOLECTRL 

CONSOLESTAT 



Offset (hex) 

00 
04 
08 

0C 



Parameters 

return data byte in DO.B 
write data byte in DO.B 
SYSCOM pointer in A0 
BREAK vector in Al 
STATREC pointer in A2 
CONTROL word in D2.W 



PRINTERREAD 
PRINTERWRITE 
PRINTERCTRL 
PRINTERSTAT 



10 
14 
18 
1C 



return data byte in DO.B 
write data byte in DO.B 
(none) 

STATREC pointer in A 
CONTROL word in D2.W 



DISKREAD 



DISKWRITE 

DISKCTRL 

DISKSTAT 



REMOTEREAD 
REMOTEWRITE 
REMOTECTRL 
REMOTESTAT 



USERWRITE 

USERCTRL 

USERSTAT 



24 
28 
2C 



30 
34 
38 
3C 



40 



44 

48 
4L' 



block number in D3.W 
byte count in D4.W 
data area address in A2 
drive number in D5.B 
CONTROL word in D2.W 
(same as DISKREAD) 
drive number in D5.B 
drive number in D5.B 
STATREC pointer in A2 
CONTROL word in D2 ,W 

return data byte in DO.B 
write data byte in DO.B 
(none) 

STATREC pointer in A2 
CONTROL word in D2.W 

block number in D3.W 
byte count in D4.W 
data area address in A2 
device number in D5.B 
CONTROL word in D2.W 
(same as USERREAD) 
device number in D5.B 
device number in D5.E 
STATREC pointer in A2 
CONTROL word in D2.W 



SYSWRITE 
SYSCTPL 



SYSSTAT 



50 



54 
58 



5C 



block number in D3.W 
byte count in D4.W 
data area address in A2 
device number in D5.B 
CONTROL word in D2 ,W 
(same as SYSREAD) 
device number in D5.B 
EVENT vector in A0 
device number in D5.B 
STATREC pointer in A2 
CONTROL word in D2.K 



QDIET 
ENABLE 

SERIALREAD 

SERIALWRITE 

SERIALCTRL 



60 
64 

68 

6C 

70 



(none) 
(none) 

return data byte in DO.B 
device number in D5.B 
write data byte in DO.B 
device number in D5.B 
device number in D5.B 
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SERIALSTAT 7 4 device number in D5.E 

STATREC pointer in A2 
CONTROL word in D2.W 
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The Operating System 



OVERVIEW OF THE OS 



The operating system is a collection of Pascal 
UNITs. The organization of UNITs in the operating 
system was determined by three considerations: 
functional grouping, space and language restrictions, 
and necessary code-sharing with other portions of 
the system. Some UNITs (such as SCREENOPS) are 
intended to be accessible to your programs as well. 
The name of a UNIT in the operating system 
generally reflects its function. This is a full list 
of operating system UNITs: 



Unit Name 

HEAPOPS 

EXTRAHEAP 

PERMHEAP 

SCREENOPS 

FILEOPS 

PASCALIO 

EXTRAIO 

SOFTOPS 

SMALLCOMMAND 
COMHANDIO 

STRINGOPS 

OSUTIL 

CONCURRENCY 

REALOPS 

LONGOPS 

GOTOXY 

KERNEL 



GETCMD 
USERPROG 
INITIALIZE 
PRINTERROR 



Function 

Heap operators 

Screen control 

File and directory operations 

File-level I/O 

I/O redirection and chaining 
String intrinsics 



Concurrency 

Floating point functions and real number I/O 

Long integer operations 

Screen cursor control (may be user-supplied) 

Nonswappable central facilities of op. system 
(always resident in main memory) 

Subsidiary segments of KERNEL 
(swappable) 
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KERNEL contains the resident code necessary to 
maintain the code pool, handle faults, and read 
segments. The Kernel also contains four subsidiary 
segments, which are swappable: 

GETCMD processes your input at the main 
command level, and builds your program's 
run-time environment; 

USERPROG is the reserved segment slot for your 
program (at bootstrap time it contains the 
Pascal-level code which builds the initial 
run-time environment for the operating system); 

INITIALIZE is called when the system is booted 
or reinitialized. It reads SYSTEM.MISCINFO, 
locates the system code files, and sets up the 
table of devices; 

PRINTERROR prints run-time error messages. 

The operating system UNITs are compiled 
separately. They are bound together in a single 
code file, SYSTEM.PASCAL, by using the utility 
LIBRARY. 

Because of certain bootstrap restrictions, KERNEL 
must always reside in segment-slot and 
USERPROG must always reside in slot 15. There 
are no other restrictions on the location of units 
within SYSTEM.PASCAL. 
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P-MACHINE SUPPORT 



The Heap: An Overview 

The heap is an area in low memory used for the 
allocation of dynamically stored variables. The 
upper bound of the heap depends upon the size 
of the stack (and the code pool if it is internal). 
The area between the heap and its upper bound 
is provisionally available to the heap: stack 
faults and segment faults may change the size of 
this area. Heap faults are used by the heap 
operators to request that more space be allocated 
to the heap. 

The heap is manipulated by a number of intrinsic 
routines that allocate or deallocate heap space in 
a particular way. These routines are described 
below. 



MARK and RELEASE 

MARK saves the location of the current top of 
the heap. RELEASE cuts the heap back to the 
location of the corresponding mark. Variables 
which were allocated between the time of the 
MARK and the time of the RELEASE are 
removed from the heap, except for variables 
allocated by PERMNEW. MARK and RELEASE 
may be nested; the integrity of the heap 
requires that they be correctly paired. 
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NEW and VARNEW 

NEW and VARNEW cause variables to be 
allocated on the heap above the topmost mark. 
NEW(P), where variable P is a pointer to type 
T, causes the number of words in type T to be 
allocated. P is assigned the address of the 
first location allocated to P on the heap. If T 
is a record with variants, space for the largest 
variant is allocated. In Pascal, a call to NEW 
may designate a particular variant, so that 
space for this particular variant is allocated 
(which may be less than the largest variant in 
that record). 

VARNEW(P,NWords), where P is a pointer to 
type T, causes NWords to be allocated on the 
heap. T would most commonly be an array. 
NWords (indirectly) determines how many 
elements of the array are actually available in 
this instance. P returns the address of the 
first location allocated on the heap. 

VARNEW is a function, and returns the number 
of words that actually were allocated. This 
should equal NWords; if it is 0, then there was 
less than NWords of available space, and if it 
is some other number, something went wrong. 
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DISPOSE and VARDISPOSE 

DISPOSE and VARDISPOSE de-allocate space 
reserved by NEW and VARNEW, respectively. 
DISPOSE(P) frees the number of words pointed 
to by P. VARDISPOSE(P,NWords) frees NWords 
words. In both cases, P is assigned the value 
NIL. 

To avoid destroying important information that 
is on the heap, extreme caution should be used 
with these intrinsics, which do little 
error-checking of their own. Heap space 
allocated by a VARNEW should be freed only 
by a VARDISPOSE with the same NWords 
parameter, and MARK/RELEASE pairs should 
always match. Furthermore, if the NEW is 
called for a specific variant, the same variant 
should be used to DISPOSE that area. 

If these intrinsics are misused, the system is 
likely to crash. This is the least mysterious of 
the symptoms that may occur. 



PERMNEW and PERMDISPOSE 

A variable can be allocated on the heap by 
PERMNEW(P), where P is a pointer to the 
variable's type. A variable allocated by 

PERMNEW can only be deallocated by 
PERMDISPOSE(P). Even a RELEASE can't 
remove it. These routines are meant for the 
system's use, not yours. 
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The operating system uses these routines to 
allow variables to remain defined across 
MARK/RELEASE pairs. Program CHAIN 
commands are saved on the heap with 
PERMNEW, so that even after the chaining 
program terminates, and its heap space is 
released, these commands are still available to 
determine the further actions of the system. 



Heap Implementation 



Unit Organization 

Code for the heap operators is contained in 
three units: HEAPOPS, EXTRAHEAP, and 
PERMHEAP. HEAPOPS contains MARK, 

RELEASE, and NEW. EXTRAHEAP contains 
DISPOSE, VARNEW, VARAVAIL, MEMLOCK, 
and MEMSWAP. PERMHEAP contains 

PERMNEW, PERMDISPOSE, and PERMRELEASE. 
(VARAVAIL MEMLOCK and MEMSWAP are for 
segment management and are discussed 
elsewhere.) 
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Heap Globals 

The operating system uses several variables 
to manage the heap. The heap is maintained 
by a linked list of MARKs. The topmost 
MARK is indicated by HeapInfo.TopMark. A 
MARK (also called an HMR, for heap mark 
record) has the following structure: 



TYPE 
MemLink = RECORD 

Avail_list: MemPtr ; 
NWords: integer; 
CASE Boolean OP 
true: (Last_Avail r 

Prev_Hark: MemPtr); 
END; 



In a MARK, NWords is always 0, and the 

vanaiu 10 a±Tnayo ii\i>ij. ^ivutuo iS U 

because the MARK merely marks a location 
on the heap, and doesn't reserve any space. 

Each MARK points to an Avail_List, which is 
a list of records of type MemLink. These 
records are FALSE variants of MemLink, and 

VTTiT— _ J— A~I i.1 I _.tf a_ _.ff 

an»»ui"us cuiuams uiu iiumuur ui wurus ui 

available space (including the two words of 
the record itself). The Avail_List chain is 
ended by an Avail_List of NIL. 

The first MARK on the heap contains a 
Prev_Mark of NIL. All successive MARKs 
point back to their predecessor, so that the 
MARK chain can be traversed. 
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For each MARK, the first AvailJList record 
is the lowest unallocated space above the 
MARK. Last_Avail points to the last of the 
available space. This is typically bounded by 
allocated heap space or by another MARK; if 
the MARK is TopMark, Last_Avail is bounded 
by the code pool if the pool is internal or 
by the stack if the pool is external. 

The heap maintenance variables have the 
following structure: 



VAR 
Heaplnfo: RECORD 

Lock: semaphore; 
TopMark, 

HeapTop: HemPtr; 
END; 
PermList: MemPtr; 



The Lock semaphore guarantees that the 
heap is modified by only one process at a 
time. TopMark points to the highest MARK. 
HeapTop points to the highest allocated 
space on the heap. The Faulthandler uses 
HeapTop to determine how close the code 
pool or the stack can be to the heap. A 
base value is computed which is either the 
base of the code pool (if internal) or SP_Low 
(if the pool is external). PermList points to 
a linked list of PERMNEW'ed variables. The 
list is identical in structure to an Avail_List, 
but each NWords indicates the number of 
words allocated by a PERMNEW. If PermList 
is NIL, then no variables have been 
PERMNEW'ed. 
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Tactics 

In general, a request for heap space through 
a MARK, NEW, VARNEW, or PERMNEW 
causes HeapTop to be set to the new top of 
the heap. The fault handler always places 
the code pool (located at PoolBase) above 
HeapTop if the pool is internal. If the pool 
is external, the stack and heap are allowed 
to grow toward each other. If they meet, a 
stack overflow condition exists. Thus, 

HeapTop reserves space for the heap as soon 
as a heap operator requests it. This is 
necessary because of possible interactions 
between stack fault handling and heap space 
allocation. 

The operating system uses the global variable 
SysConT.GDirP (global directory pointer) to 
allocate a disk directory on the heap. The 
operating system's use of this heap space is 
meant to be invisible to you. Therefore, 
before any heap operation (except DISPOSE), 
SYSCO Nf.GDirP is DISPOSEed to make the 
space occupied by the directory avauabie 
again. 
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Run-Time Environment 



Since both you and the operating system use 
the heap, the operating system MARK'S the 
heap immediately before the execution of your 
program by the call: 



HARK (EHPTYHEAP) ; 



After your program terminates, the operating 
system calls: 



RELEASE (EMPTYHEAP) i 



Thus, all your space is freed after the program 
terminates, unless space has been allocated by 
one or more calls to PERMNEW. 

MARK (EMPTYHEAP) occurs after the run-time 
environment for your program has been built. 
The program's run-time environment structures 
such as SIBs, E_Rec's, and E_Vect's, are for 
the use of the operating system, and are 
allocated space before EMPTYHEAP. Data 
that is global to your program and any units it 
USES also appears before EMPTYHEAP. Heap 
space that follows EMPTYHEAP is intended 
only for the local use of your program. 

The heap is shared by all tasks in the system. 
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THE CODE POOL 



The code pool resides in main memory between the 
stack and the heap. It contains executable code 
segments that may possibly be discarded, or 
swapped in from disk again. Thus, the contents, 
size, and position of the code pool may change 
during a program's execution. The flexibility of 
code pool handling can provide a running program 
with more free memory space than in previous 
versions. 

A segment in the code pool must be either p-code 

or relocatable native code. Nonrelocatable native 

code segments reside on the heap; they are placed 
there at associate time. 

The code pool is a contiguous block of code 
segments— whenever a segment is discarded, the 
surrounding segments are moved together. Segments 
being swapped in are given space at either end of 
the eode pool. 



segments in the code pool are organized into a 
doubly-linked list by pointers in each segment's SIB 
(described in the previous chapter). 
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The routines that manage the code pool are in the 
operating system's KERNEL unit. They make use 
of the following global values: 



SegPool: "PoolDes; 



This field is within the 
SIB. It points to a 
description of the code 
pool, which is declared as 
follows: 



PoolBase: Full Address; 



Pooldes = Record 






PoolBase : 


fulladdress; 


PoolSize : 


integer ; 




MinOffset : 


memptr; 




MaxOffset : 


memptr; 




Resolution : 


intergei 


; Cin bytes) 


PoolHead : 


SIB_P; 




Perm_SIB : 


SIB_P; 




Extended : 


boolean; 




End; 






iress; Points to 


the 


memory 


location at 


: the 


base of 


the code 


pool. 


(A 


Full_Address is 


a 32-bit 


address.) 







PoolSize: Integer; 

MinOffset: Integer; 
MaxOffset: Integer; 



The size of the code pool 
in words. Set by the 
SETUP utility. 

Lower boundary of code 
pool. 

Upper boundary of code 
pool. 
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Resolution: Integer; 



PoolHead: SIB_P; 



PermSIB: SIB_P; 



Extended: Boolean; 



SP_Low: Mem_Ptr; 



A segment must be placed 
in memory starting at a 
location which has an 
address that is a multiple 
of this number. This is 
set by the SEGMENT 
ALIGNMENT field in 
S YSTEM.M ISCINFO 
(determined by the SETUP 
utility). 

Points to the SIB of the 
segment at the base of 
the code pool (next to 
the heap). 

Points to the SIB of the 
segment that is always 
resident in the code pool 
(currently, GOTOXY). 

True if extended memory 
is used; false, otherwise. 
Set from the HAS 
EXTENDED MEMORY 
field in 

SYSTEM. M ISCINFO 
(determined by the SETUP 
utility). 

The lowest possible bound 
of the stack; this points 
to the address which is 
one word above the top 
of the code pool (if it is 
internal). SP_Low is in 
the TIB. 
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HeapTop: MemJPtr; Points to the top of the 

heap. HeapTop is part of 
the Heaplnfo record. 

If the code pool is internal when space is requested 
either for the heap or the stack, the code pool 
management routines first attempt to reposition the 
code pool without swapping out any segments. 

The actual bounds of the code pool are in 
MinOffset, which points to the low end of the code 
pool, and MaxOffset, which points to one word 
above the top of the code pool. The code pool 
operators may move the pool all the way to 
HeapTop on the heap side, or up to SP minus a 
40-word margin on the stack side (if the pool is 
internal). MaxOffset is the same as SP_Low for an 
internal pool. 

An internal code pool may be modified under any 
of the following circumstances: 

1. A heap fault is detected, and the code pool is 
moved up in memory toward the stack to free 
the needed number of words for the heap. 

2. A staek fault is detected, and the code pool is 
moved down in memory toward the heap to free 
the needed number of words for the stack. 
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3. A heap fault or stack fault is detected, and the 
code pool can't be moved to allocate the space; 
one or more segments are swapped out, the 
remaining segments are moved together, and the 
code pool is positioned to allow for the needed 
heap or stack space. 

4. A heap or stack fault is detected, and even 
after swappping out all of the swappable 
segments, not enough space is available; a stack 
overflow error is reported, and the system is 
reinitialized. 



An internal or external code pool may be modified 
when a segment fault is detected. The code pool 
management routines first try to read the segment 
in at either end of the code pool without moving 
it. Ii this is impossible, and the pool is internal, 
they attempt to create more room by moving the 
code pool toward either the stack or the heap, and 
then read the segment. If this too is impossible, or 
the pool is external, segments are swapped out to 
make room, and the new segment is then read in. 
If this last effort also fails, a stack overflow error 
is reported if the pool is internal or a pool 
overflow error is reported if the pool is external. 
The system is reinitialized. 

The code pool management routines are only called 
by the Faulthandler. Since the Faulthandler is a 
subsidiary task, its own stack is statically 
allocated. Thus, the Faulthandler can manipulate 
the code pool freely, without fear of causing a 
stack fault. 
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Fault Handling 

When memory space is required by the stack or 
heap, or entry into a nonresident segment is 
attempted, a fault is issued. The Faulthandler 
process is activated, and uses the code pool 
management routines to rearrange main memory 
(as described in the previous section). 

The Faulthandler is a process that is STARTed at 
bootstrap time. Most of the time it is idle, it 
WAITs for a semaphore. When the semaphore is 
SIGNALed, the Faulthandler is activated and 
performs its memory management functions. 

Faults can be SIGNALed by the PME (stack and 

segment faults), or by the EXECERROR 

procedure in the operating system (heap faults 
and one segment fault). 

The semaphore record used by the Faulthandler 
resides in SYSCOM. It is declared as follows: 



Fault_Message = RECORD 

Fault_TIB: TIB_Ptr; 
Fault_E_Rec: E_Rec_Ptr; 
Fault_Words: integer; 
Fault_Type: Seg_Fault .. Pool_Fault; 
END; 

Fault_Sem: RECORD 

Real_Sem, Message_Sem: semaphore; 
Message: Faultjessage; 
END; 
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The PME detects only stack and segment faults. 
When the PME detects a fault, it places the 
appropriate information in FauItJSem.Message and 
SIGNALS Fault_Sem.Message_Sem. The SIGNAL 
causes a task switch to the Faulthandler, and the 
fault is processed. After it has dealt with the 
code pool, Faulthandler WAITs— this causes a task 
switch back to the previously running process. 
The instruction that caused the fault is 
reexecuted. 

The operating system issues heap faults, and in 
one instance, a segment fault. Heap faults are 
detected by the heap operators when requests are 
made for heap space by MARK, NEW, VARNEW, 
and PERMNEW. The one segment fault is issued 
by MEMLOCK if a segment to be locked in the 
code pool isn't already resident. To issue a 
fault, the operating system calls the execution 
error procedure (EXECERROR), and passes it the 
needed information. EXECERROR then performs 
a SIGNAL on Message_Sem. 

The Faulthandler first ensures that the currently 

piinnincr cpcrniont ion't siuonnoH mit artri then ncec 

the code pool management routines to adjust the 
main memory layout. 

If a stack fault is caused by a call to a routine 
in a different segment, Faulthandler must lock 
both calling and called segments into memory. 
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Concurrency 

Operating system routines support concurrency 
only by the activation and deactivation of 
processes; actual task switching is accomplished 
by the p-machine operations SIGNAL and WAIT. 

Concurrency support is intended for low-level 
tasks. Most system-level facilities, particularly 
I/O, are synchronous. For instance, a READ or 
U NITRE AD from the console doesn't return to 
the caller until a character is available. No task 
switch can occur during the waiting period. 

The operating system global variable Task_Info is 
used to keep track of some of the data for 
subsidiary processes. Its structure is as follows: 



Task_Info: RECORD 

Lock , 

Task_Done: semaphore; 
N_Tasks: integer; 
END {of Task_Info); 



Task_Info.Lock is used to ensure mutual exclusion 
while changing the values of other Task_Info 
fields. Task_Done is used to WAIT for the 
termination of any subsidiary processes. N_Tasks 
is the number of subsidiary tasks that have been 
STARTed. 
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The unit CONCURRENCY has three routines: 
START, STOP, and BLK_EXIT. For each process 
initiation, the compiler emits initialization code 
that signals the semaphore passed to START. 
The compiler also emits a call to STOP in the 
exit code of each process; a call to BLK_EXIT is 
part of the exit code of a main process. 

START builds the data structures for a new task 
and sets it in execution. The task's TIB, 
activation record, and stack space are allocated 
on the heap, and the operating system forces a 
task switch by issuing a WAIT. Presumably, the 
new process starts executing, and switches back 
to START by doing a SIGNAL after its 
parameters have been copied. Actually, when 
START performs the WAIT, it is the process with 
the highest priority that begins executing, 

STOP records the termination of a process. It 
decrements Task_Info.N_Tasks, SIGNALS 
Task_Info.Task_Done, and then initializes and 
waits for a dummy semaphore in order to force a 
permanent task switch from the terminating 



BLK_EXIT is called by a main task, and waits 
for the termination of all subsidiary tasks. It 
waits on Task_Done, and terminates the main 
task when N_Tasks equals zero. 
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I/O SUPPORT 



FIBs 



File I/O is controlled with a. structure called a 
FIB (File Information Block). When you declare a 
file, the compiler emits code to initialize a FIB 
for that file. A FIB is declared as follows: 



FIB = RECORD 

FWindow: Window_P; 
FEOF, FEOLN: Boolean; 

FState: (FJandW, FNeedChar, FGotChar) ; 
FRecSize: integer; 
FLock : semaphore; 
CASE FlsOpen: Boolean OF 
true: (FIsBlkd: Boolean; 
FUNIT:UMTNUK; 
FVIDlVID: 
FEeptCnt, 
FNxtBlk, 

FWaxBlk: integer; 
FHodified: Boolean; 
FHeader: DirEntry; 
CASE FSoftBuf: Boolean OF 

true: (FNxtByte, FMaxByte: integer; 
FBufChngd: Boolean; 

FBuffer: PACKED ARRAY [ . .FBlkSize] 
OF CHAR) ) 
END {of FIP.} 



FWindow points to the current character in the 
file's buffer. FEOF and FEOLN are the EOF 
and EOLN flags. FState indicates that the file 
is either a standard (Jensen and Wirth) file, an 
INTERACTIVE file awaiting a character, or an 
INTERACTIVE file with a character. FRecSize 
is for unentered files, 1 for INTERACTIVE 
files and text files; if it is larger than zero, it 
indicates the size (in bytes) of a record. FLock 
is used to ensure that only one process at a time 
may modify the file. FlsOpen is TRUE only 
when the file is open. 
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If FIsOpen is TRUE, then several other fields 
become relevant. FIsBlkd is TRUE if the file 
resides on a storage device. FDev is the number 
of that device, and FVolID is the name of the 
volume. FReptCnt contains a count of the 
number of times the window value is valid before 
another GET is needed. FNxtBlk is the next 
(relative) block to access. FMaxBlk is the 
maximum (relative) block that can be accessed. 
FModified becomes TRUE if the file is modified; 
a new date is then set in the directory. 
FHeader is a copy of the file's directory entry. 
FSoftBuf is TRUE if soft-buffered I/O is used. 
This is the case for all files on storage device, 
except unentered files. 

If FSoftBuf is TRUE, then the last set of FIB 
fields are used. FNxtByte and FMaxByte are 
used for buffer handling, FBufChngd indicates 
that the buffer contents have been modified, and 
FBuffer is the buffer itself. 
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Directories 



Figure 5-1 illustrates the structure of a directory 
(as on a disk or other storage device). 



DIRENTRY RECORD (0) 
for dfktnd=securedir, untyped file (dir[Q] ) 



filler_1 



dfkind 



length (7) 



deovblk 



dnumfiles 



dloadtime 

(year) | (day) | (month) 



DIRENTRY RECORD ( 1-77) 



status 
bit 



dfirstblk 


dlastblk 


- | filler_2 




I dfkind 


length (IS) 


1 


2 


3 


4 


5 


6 J 


7 


8 


9 


10 


11 


12 


13 


14 


15 


dlastbyte 


(year) 


[ (day) 


| (month) J 



DIRECTORY: array [0..77] ofdirentry; 






1 


• • • 


77 



Figure 5-1. Directory Format 
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VARIETIES OF I/O 
Record I/O 



Record I/O applies to entered Pascal files, using 
the intrinsics GET and PUT. 



Screen I/O 

Screen I/O may be handled by the unit 
SCREENOPS, whose routines are described in the 
following section. 

Input from the screen is accomplished by the 
procedure CHAR_DEV_GET, which uses 
SC_CHECK_CHAR (in SCREENOPS) and 
SYSCOMMWISCINFO to determine whether any 
special handling needs to be done. 

Output to the screen is accomplished by a simple 
UNITWRITE. 



Block I/O 

Block I/O applies to unentered files. The 

routines BLOCKREAD and BLOCKWRITE are 
used. These are part of the system routine 
FBLOCKIO in the EXTRAIO unit. 

When a file is accessed as an unentered file, all 
other file formatting is disabled. 
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Text I/O 

A text file is a file of ASCII characters. It has 
a 2-block header that contains formatting 
information used by the Screen Oriented Editor. 
When a text file is used by a system program 
other than the editor, the operating system 
ignores this header. When a new text file is 
created, the operating system writes a 2-block 
header filled with NULs. When SofTech's 

internal part number is added to a text file, it is 
stored in the last two words of the header (end 
of block 1). 

Text files always have an even number of blocks. 
Thus, the smallest possible text file is four 
blocks long. Each pair of blocks after the 
header is considered as a "page." Each page 
contains lines of text terminated by <return>. 
The last line of text in a page must not be 
continued on the next page in the text file. 
Extra space after the last line in each page must 

I J*!tt _ J 2J.1- 1TTTT - /J..: u .l ft\ 

Each line in a text file may optionally start with 
a DLE (decimal 16), which is interpreted as a 
blank compression code. The byte following a 
blank compression code is ASCII code 32+n, 
where n is the number of leading blanks. This 
blank compression code is generated by the editor 
(chiefly for the purpose of saving space in 
indented program source). 
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Your programs typically handle text files with 
READ, READLN, WRITE, and WRITELN. GET 
and PUT may be used, and follow the Jensen and 
Wirth standard for files of type TEXT. 
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Program Execution 



BUILDING A RUN-TIME ENVIRONMENT 

The run-time environment for your program is 
created by the operating system's GETCMD unit. 
GETCMD starts the execution of system programs 
such as the compiler, linker, filer, and so on, and 
your programs named in the X(ecute command. In 
all such cases, GETCMD calls the procedure 
ASSOCIATE, which finds the appropriate code file, 
and then calls BUILDENV. BUILDENV constructs a 
program's run-time environment, as outlined in 
Chapter 3, "The P-Machine." 

BUILDENV recursively traverses the segments used 
by a program. For each segment, it initializes an 
E_Vect, E_Rec, and SIB. As each E_Rec is 
created, it is linked to a chain of segments that 
are already active. In this way, the operating 
system can keep track of all active segments. 
Before BUILDENV initializes segment information, it 
checks to see if that segment is already active, 
and if it is, it does nothing but initialize the 
proper pointers. Otherwise, the E_Vect, ERec, 
and SIB must be created from information present 
in the code file. 
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SEGREFs are segment reference assignments 
emitted by the compiler. Segment numbers are 
local to a code segment. The main program is 
segment 2, and subsidiary segments, if any, are 
numbered starting from 3. Segment 1 is always the 
operating system's KERNEL unit. SEGREFs are 
emitted for any principal segments used by the 
compilation (such as a used unit). At associate 
time, BUILDENV uses the SEGREF list to find the 
segments that the program uses. 

All run-time errors detected by the system cause 
the current program to halt. The system displays 
an error message, and when you press <space>, the 
system is reinitialized. The program's run-time 
environment is lost. 

When a program terminates, control returns to 
GETCMD, which waits for further instructions. 
When a program terminates normally, its 
environment is not lost, and the program can be 
restarted with the U(ser restart command. The 
system may or may not need to call BUILDENV 
again. 
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QUICKSTARTING PROGRAMS 

The QUICKSTART utility (described in the 
Operating System Reference Manual) constructs a 
description of the execution environment for a 
program and generates a code file for the program 
which contains this execution environment 
description. The GETCMD unit detects the 

presence of execution environment descriptions 
within code files and attempts to reconstruct the 
required execution environment from such 
descriptions when the programs are invoked. In 
this section, an execution environment description 
built by the QUICKSTART utility is caUed a 
"Program Environment Descriptor" or "PED" for 
short. 
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Program Invocation Overview 

When the execution of a program is requested, 
the system first inspects the code file to 
determine if an execution environment description 
is present within it. If such a description is 
present, the system attempts to reconstruct the 
execution environment required by the program 
from the description in the code file. If the 
code file doesn't contain an environment 
description, or the environment description 
contained within the code file is determined to 
be obsolete, the system attempts to build the 
environment for the program in the normal 
manner. 

The program invocation process begins with an 
attempt at opening the code file. If the code 
file is sucessfully located, and the file is judged 
to be a code file (based on directory 
information), then the segment dictionary is read 
from block zero. Within the segment dictionary 
are two fields which indicate the presence, size, 
and location of an imbedded PED. (See 
description of the segment dictionary structure in 
the next section.) 
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If the PED_BLK field of the segment dictionary 
isn't zero, a PED exists within the code file, and 
an attempt is made to reconstruct the execution 
environment for the program using the 
information stored in the PED. If this 

reconstruction of the execution environment fails, 
the system automatically attempts to construct 
the program's execution environment using the 
normal execution environment construction 
process. When the PED_BLK word contains zero, 
the normal execution environment construction 
process is used. 

A PED completely describes the execution 
environment required by a program. A detailed 
description of the structure of a PED is give in 
the "PED Structure" section, below. 

A PED contains a list of p-System operating 
system units which are referenced by the 
program. Each of these referenced operating 
system units must be present within the system 
environment in which the program is being 
invoked. The execution environments for these 
nnorntincr owstpm units firp created bv the 
p-System at p-System bootstrap time. The 

execution environments for referenced units which 
are resident in other library code files (such as 
SYSTEM.LIBRARY or a user library code file) are 
described completely so that the execution 
environment can be reconstructed without 
performing detailed examinations of the libraries. 
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Also included within the PED is a list of 
referenced library code files. The description of 
each library code file includes the name of the 
library code file and the name of the volume on 
which the library code file resided at the time 
the PED was constructed. Part of the 

environment reconstruction process involves 
establishing the location of each referenced 
library code file. A particular library code file 
is sought first on the volume indicated in the 
PED information, then on the prefix volume, and 
then on the root volume. 

While specific volume block offsets for referenced 
library code files aren't recorded within a PED, 
the relative block locations of segments within 
the various referenced library code files are 
recorded. A mechanism is required to assure 
that this internal code file configuration is the 
same at program invocation time as it was when 
the PED was constructed. 



iii uiuci iv yciiunji uus v:nei;is., me ^uibMlflKl 

utility installs into block zero of each referenced 
library code file a number in the form of a 
16-bit checksum calculated over the entire 
contents of the library file. The QUICKSTART 
utility program only installs a new checksum into 
a referenced library code file when it lacks a 
valid checksum. The checksum value zero is 
reserved to indicate the absence of a valid 
checksum. The p-System compilers and 

assemblers create code files with the checksum 
field set to zero. The p-System LIBRARY utility 
program clears the checksum field when it 
creates a new output code file. 
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A copy of the checksum for each referenced 
library code file is also stored within the PED. 
During the environment reconstruction process, 
the checksum in each library code file is 
compared with the corresponding checksum in the 
PED. If the checksums aren't the same, the 
configuration which existed at QUICKSTART time 
has changed, and the reconstruction of the 
execution environment using the information 
stored in the PED is aborted. Thus, whenever a 
referenced library code file is modified, any 
PEDs which reference that library code file 
become obsolete. 

The following is a rough sketch of the steps 
taken by the system when reconstructing the 
execution environment for a program from a PED: 

• Using the information stored in block zero of 
the code file, read the contents of the PED 
into a temporary buffer. 

■ Extract the list of system unit names from the 
PED and locate the E_Rec for each of the 
referenced system units. 

■ Extract the referenced library code file 
descriptors from the PED. As each descriptor 
is extracted, establish the location of the 
specified library eode file by searching the 
following volumes: the volume specified in the 
descriptor, the prefix volume, the root volume. 
Report an environment reconstruction failure 
if a particular library code file can't be 
located, or if the checksum stored in a 
located library code file doesn't match the 
checksum in the corresponding descriptor in 
the PED. 
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Allocate enough memory to contain the 
E_Vect's, E_Rec's, and SIBs which are 
neeessary to represent the execution 
environment for the program. 

Extract the set of E_Vect templates from the 
PED and move them into position. 

Examine each E_Vect, converting each of its 
entries from a "global segment number" to a 
pointer to the appropriate E_Rec structure. 

Extract the set of SIB templates from the 

PED and construct the SIBs for all of the 

units and subsidiary segments within the 
program's execution environment. 

Link the E_Rec's for the principal segments 
within the environment into the system's list 
of active E Rec's. 



Segment Dictionary Structure 

Figure 6-1 shows the revised structure of block 
zero of a p-System code file after new fields 
related to QUICKSTART have been assigned. 
The five words which are labeled in the figure 
correspond to the five unused words in the 
original block zero structure. 
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From this figure, it ean be seen that the first 
previously unused word has been allocated to hold 
a checksum for the code file. (The usage of this 
checksum was described in the previous section.) 

The next new field is called PED_BLK and is the 
relative block number within the code file where 
the PED is located. If the PED_BLK word 
contains zero, the code file doesn't have a PED. 
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The third new word is called PED_BLK_COUNT 
and contains the size of the PED in blocks. 





Segment Dictionary 1 
Information 1 




NEXT_DICT 1 




unused 1 






1: 


CHECKSUM 1 


2: 


PED_BLK 1 


3: 


PED_BLK_COUNT 1 


4: 

5: 


Reserved For 1 
SofTech Part Number 1 




Copyright Notice 1 




Byte Sex Indicator 1 



Figure 6-1. Code File Block Zero Structure 
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PED Structure 



The general structure of a PED is illustrated in 
Figure 6-2. From this figure, it can be seen 
that a PED begins with a header record. This 
record contains global information about the 
program and about the remaining structures 
contained within the PED. The structure of this 
header record is defined by the PED_HEADER 
type declaration shown in Figure 6-2. 

The PED_BYTE_SEX field of the header record 
indicates the byte sex of the PED. A value of 1, 
is placed into this field at the time the PED is 
constructed. If at program invocation time this 
field contains the value 256, then the PED has 
the opposite byte sex from the byte sex of the 
processor on which the quickstarted program is 
being invoked. 

The PED_LAST_SYSTEM_SEGMENT field of the 
PED_HEADER record contains the number of 
operating system segments which are referenced 
by the execution environment for the program 
described by the PED. This field of the header 
record is set to the value zero if the PED 
describes the execution environment of the 
operating system itself. 



0400101:06A 6-13 



Program Execution 



PED_HEADER 



System Unit Name 
System Unit Name 



library file descriptor 
library file descriptor 



PED_EVEC 



PED_EVEC 



PED_PSUEDO_SIB 
PED_PSEUDO_SIB 



Sequence of 
referenced 
system unit 
names. 



Sequence of 
library code 
file 
descriptors. 



Sequence of 
variable length 
E_Vect templates, 
with global 
segment numbers. 



Sequence of 

pseudo siBs 

with library 

number and 

library 

relative 

disk locations. 



Figure 6-2. General PED Structure 
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type: {PED header record.} 

ped_header = 
record 

ped_byte_sex: integer; 

{PED Byte sex indicator.} 

ped_forrriat_level : integer; 

{PED structures 
version indicator.} 

ped_library_count : integer ; 

{Number of library 
file descriptors.} 

ped_pr inc ipal_segment_count : integer ; 

{Number of principal 
segments described.} 

ped_subsidiary_segment_count: integer; 
{Number of 
subsidiary segments 
described. } 

ped_total_evec_words: integer; 

{Size of BVEC 
templates . } 

ped_last_system_segment : integer ; 

{Number of system 
segments referenced 
by environment.} 

ped_start_unit : integer; 

{Global segment 
number of 
principal segment 
where execution 
should begin,} 

ped_uses_realops_unit: boolean; 

{TRUE if REALOPS 
unit required.} 

ped_expansion_area: 

array [1. .5] of 0. .0; 

{Reserved for 
future use.) 
end; 



Figure 6-3. PED Header Structure 
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Following the PED_HEADER record is a sequence 
of 8-character system unit names. The number 
of names in the sequence is given by the 
PED_LAST_SYSTEM_SEGMENT field of the 
PED_HEADER record. Each name in the 
sequence is the name of a system unit whieh is 
referenced by the execution environment 
described by the PED. 

The list of system unit names is followed by a 
sequence of library file descriptors. The number 
of library file descriptors is given by the 
PED_LIBRARY_COUNT field of the 
PED_HEADER record. Each library file 

descriptor contains a word with the checksum for 
the referenced library file, followed by a string 
identifying the volume the library file should be 
located on and a string containing the title of 
the library file. These strings occupy the 

minimum number of words required for the string 
value. For each of these string values, if the 
length of the string plus the length byte is odd, 
a padding byte of zero will follow the string to 
cause the string to occupy an integral number of 
words in the PED. 
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The library file descriptors are in turn followed 
by a sequence of E_Vect templates. There are a 
total of PED_PRINCIPAL_SEGMENT_COUNT 
E_Vect templates which occupy 
PED_TOTAL_EVEC_WORDS in the PED. These 
E_Vect templates are exactly the same size as 
the E_Vect's which are needed to represent the 
execution environment of the program. 

Each of these E_Vect templates begins with a 
word containing the number of entries in the 
E_Vect. This count word is in turn followed by 
the words for the E_Vect entries. The EVect 
entries are followed in the template by an extra 
entry (one word in length) which is required by 
the operating system. 

Each of the E_Vect entries stored in the E_Vect 
templates of the PED references a particular 
segment of the program's environment via a 
"global segment number." 

The global segment number zero is reserved to 
denote an empty E_Vect entry which should be 
initialized to the value NIL. 

An E_Vect entry containing a negative global 
segment number in the 

range-PED_LAST_SYSTEM_SEGMENT..-l denotes 
a reference to a system segment. The identity 
of the referenced system segment is established 
by using the absolute value of the global segment 
number as an index into the sequence of system 
segment names. 
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An E_Vect entry containing a positive global 
segment number in the range 
l..~(PED_PRINCIPAL_SEGMENT_COUNT + 
PED_SUBSIDIARY_SEGMENT_COUNT) indicates a 
reference to the E_Rec for one of the segments 
of the environment described in the PED. The 
E_Rec structure for a given nonsystem segment is 
located by using the global segment number as an 
index into an array of E_Rec structures which is 
allocated at environment reconstruction time. An 
index value in the range 

l..PED_PRINCIPAL_SEGMENT_COUNT selects the 
E_Rec for one of the principal segments within 
the execution environment. An index value which 
is greater than 

PED_PRINCIPAL_SEGMENT_COUNT specifies a 
reference to one of the subsidiary segments 
within the program execution environment. 

Following the E_Vect templates in the PED is a 
sequence of M pseudo-SIB" records. The structure 
of a pseudo SIB is defined in Figure 6-4. Each 
pseudo SIB is a template for a fragment of an 
actual SIB, which must be allocated when the 
program's execution environment is reconstructed. 
Thus, there exists one pseudo SIB for each 
nonsystem segment in the environment. The 
pseudo SIBs for the principal segments appear 
first in the sequence followed by the pseudo SIBs 
for the subsidiary segments in the environment. 
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type 

ped_pseudo_sib = 
record 

ps_seg_name: alpha; 

{Name of segment.} 

ps_seg_leng: integer; 

{Length of segment.} 

ps_seg_addr: integer; 

{Relative block 
address of segment 
in library file.} 

ps_seg_data_size: integer; 

{Size of segment 
data area.} 

ps_seg_lib_num: integer; 

{Index into sequence 
of library code 
file descriptors.} 

ps_seg_attributes: 
packed 
record 

ps_relocatable: boolean; 
{Relocatable 
indicator from 
segment 
dictionary. } 

ps_ii<cich_type: m_types; 
{Type of code in 
segment . } 

ps_filler: 0..2047; 

{11 bits of filler 
to round out to 
one word. } 
end; 
end; 



Figure 6-4. Pseudo SIB Structure 
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The information stored in each pseudo SIB 
structure consists of the information from the 
segment dictionary entry for the segment which 
is needed to construct the actual SIB when the 
program's environment is reconstructed. The 
PS_SEG_LIB_NUM field of a pseudo SIB is used 
to establish the identity of the library code file 
which contains the segment described by the 
pseudo SIB. This identity is established by using 
the PS_SEG_LIB_NUM field as an index into the 
sequence of library file descriptors within the 
PED. The index value one selects the first 
library file descriptor in the sequence. 
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APPENDIX A 

P-MACHINE OPCODES 

(Alphabetic Order) 



O pcode 



ABI 


224 


E0 


ABR 


227 


E3 


AD I 


162 


A2 


ADJ 


199 


C7 


ADR 


192 


CO 


ASTR 


235 


EB 


BNOT 


159 


9F 


BPT 


158 


9E 


CAP 


171 


AB 


CFP 


151 


97 


CGP 


145 


91 


CHK 


203 


CB 


CIP 


146 


92 


CLP 


144 


90 


CSP 


172 


AC 


CSTR 


236 


EC 


CXG 


148 


94 


CXI 


149 


95 


CXL 


147 


93 


DEC I 


238 


EE 


DIF 


221 


DD 


DUP1 


226 


E2 


DUPR 


198 


C6 


DVI 


141 


8D 


DVR 


195 


C3 


EFJ 


210 


D2 


EQBYT 


185 


B9 


EQPWR 


182 


B6 


EQREAL 


205 


CD 


EQSTR 


232 


E8 


EQUI 


176 


B0 


FJP 


212 


D4 


FJPL 


213 


D5 


FLT 


204 


CC 


GEBYT 


ii-7 


BB 


GEPWR 


184 


B8 


GEQI 


179 


B3 


GEREAL 


207 


CF 


GESTR 


234 


EA 


GEUSW 


181 


B5 


INC 


231 


E7 


INCI 


237 


ED 


IND 


230 


E6 


INN 


218 


DA 


INT 


220 


DC 


IXA 


215 


D7 


IXP 


216 


D8 


LAE 


155 


9B 


LAND 


161 


Al 


LAO 


134 


86 


LCO 


130 


82 


LDA 


136 


88 


LDB 


167 


A7 


LDC 


131 


83 


LDCB 


128 


80 



D££ H£jt Description 



Absolute Value Integer 

Absolute Value Real 

Add Integer 

Adjust Set 

Add Real 

Assign String 

Boolean Not 

Break point 

Copy Array Parameter 

Call Formal Procedure 

Call Global Procedure 

Check Subrange Bounds 

Call Intermediate Procedure 

Call Local Procedure 

Copy String Parameter 

Check String Index 

Call External Global 

Call External Intermediate 

Call External Local 

Decrement Integer 

Set Difference 

Duplicate One Word 

Duplicate Real 

Divide Integer 

Divide Real 

Equal False Jump 

Equal Byte Array 

Equal Set 

Equal Real 

Equal String 

Equal Integer 

False Jump 

False Jump Long 

Greater Than or Equal Byte Array 

Greater Than or Equal Set 

Greater Than or Equal Integer 

Greater Than or Equal Real 

Greater Than or Equal String 

Greater Than or Equal Unsigned 

Increment 

Increment Integer 

Index 

Set Membership 

Set Intersection 

Index Array 

Index Packed Array 

Load Extended Address 

Logical And 

Load Global Address 

Load Contant Offset 

Load Intermediate Address 

Load Byte 

Load Constant 

Load Constant Byte 



0400101.-0AA 



A-3 



Appendix A 



LDCI 


129 


81 


Load Constant Integer 


LDCN 


152 


98 


Load Constant NIL 


LDCRL 


242 


F2 


Load Constant Real 


LDE 


154 


9A 


Load Extended 


LDL 


135 


87 


Load Local 


LDH 


208 


DO 


Load Multiple 


LDO 


133 


85 


Load Global 


LDP 


201 


C9 


Load Packed 


LDRL 


243 


F3 


Load Real 


LEBYT 


186 


BA 


Less Than or Equal Byte Array 


LEPWR 


183 


B7 


Less Than or Equal Set 


LEQI 


178 


B2 


Less Than or Equal Integer 


LEREAL 


206 


CE 


Less Than or Equal Real 


LESTR 


233 


E9 


Less Than or Equal String 


LEUSW 


180 


B4 


Unsigned Less Than or Equal 


LLA 


132 


84 


Load Local Address 


LNOT 


229 


E5 


Logical Not 


LOD 


137 


89 


Load Intermediate 


LOR 


160 


A0 


Logical Or 


LPR 


157 


9D 


Load Processor Register 


LSL 


153 


99 


Load Static Link 


MODI 


143 


8F 


Modulo Integers 


MOV 


197 


C5 


Move 


MP I 


140 


8C 


Multiply Integer 


MPR 


194 


C2 


Multiply Real 


NAT 


168 


A8 


Enter Native Code 


NAT-INFO 


169 


A9 


Native Code Information 


NEQI 


177 


Bl 


Not Equal Integer 


NFJ 


211 


D3 


Not Equal False Jump 


NGI 


225 


El 


Negate Integer 


NGR 


228 


E4 


Negate Real 


NOP 


156 


9C 


No Operation 


RESERVE1 


250 


FA 


reserved 


RESERVE2 


251 


FB 


n 


RESERVE3 


252 


FC 


w 


RE SERVE 4 


253 


FD 


" 


RESERVES 


254 


FE 


B 


RESERVE6 


255 


FF 


w 


RND 


191 


BF 


Round Real 


RPu 


I 50 


36 


RtiLuni LLOrn FiOCeuliL't 


SBI 


163 


A3 


Subtract Integer 


SBR 


193 


CI 


Subtract Real 


SCPI1 


239 


EF 


Short Call Intermediate Proce 


SCPI2 


240 


FO 


hum n 


SCXG1 


112 


70 


Short Call Ejternal Global 


SCXG2 


113 


71 


■ it it ■ 


SCXG3 


114 


72 


i* n n it 


SCXG4 


115 


73 


n »t rc " 


SCXG5 


116 


74 


n n n ii 


SCXG6 


117 


75 


n it n n 


SCXG7 


118 


76 


it n it 


SCXG8 


US 


77 


" " " " 


SIGNAL 


222 


DE 


Signal 


SINDO 


120 


78 


Short Index 


SIND1 


121 


79 


n n 


SIND2 


122 


7A 


■ n 


SIND3 


123 


7B 


it 11 


SIND4 


124 


7C 


" " 


SIND5 


125 


7D 


n It 


SIND6 


126 


7E 


It H 


SIND7 


127 


7F 


ll » 


SLDCO 





00 


Short Load Constant 


SLDC1 


1 


01 


n n n 


SLDC2 


2 


02 


n it H 


SLDC3 


3 


03 


n it n 
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SLDC4 


4 


04 




SLDC5 


5 


05 




SLDC6 


6 


06 




SLDC7 


7 


07 




SLDC8 


8 


08 




SLDC9 


9 


09 




SLDC10 


10 


0A 


" 


SLDC11 


11 


0B 


" 


SLDC12 


12 


OC 


" 


SLDC13 


13 


0D 


■ 


SLDC14 


14 


0E 


" 


SLDC15 


15 


OP 


" 


SLDC16 


16 


10 


" 


SLDC17 


17 


11 


" 


SLDC18 


ie 


12 


n 


SLDC19 


19 


13 


" 


SLDC20 


20 


14 


" 


SLDC21 


21 


15 


n 


SLDC22 


22 


16 


" 


SLDC23 


23 


17 


it 


SLDC24 


24 


18 


" 


SLDC25 


25 


19 


" 


SLDC26 


26 


1A 


" 


SLDC27 


27 


IB 


m 


SLDC28 


28 


1C 


K 


SLDC29 


29 


ID 


" 


SLDC30 


30 


IE 


n 


SLDC31 


31 


IF 


" 


SLDL1 


32 


20 


Sho 


SLDL2 


33 


21 


■ 


SLDL3 


34 


22 


= 


SLDL4 


35 


23 


" 


SLDL5 


36 


24 


" 


SLDL6 


37 


25 


" 


SLDL7 


38 


26 


■ 


SLDL8 


39 


27 


" 


SLDL9 


40 


28 


" 


SLDLIO 


41 


29 


" 


SLDL11 


42 


2A 


■ 


SLDL12 


43 


2B 


H 


SLDL13 


44 


2C 


" 


SLDL14 


45 


2D 


" 


SLDL15 


46 


2E 


" 


SLDL16 


47 


2P 


" 


SLDOl 


48 


30 


Shoi 


SLD02 


49 


31 


" 


SLD03 


50 


32 


n 


SLD04 


51 


33 


" 


SLD05 


52 


34 


N 


SLD06 


53 


35 


m 


SLD07 


54 


36 


" 


SLD08 


55 


37 


" 


SLD09 


56 


38 


" 


SLDOl 


57 


39 


R 


SLDOl 1 


58 


3A 


■ 


SLDOl 2 


59 


3B 


H 


SLDOl 3 


60 


3C 


" 


SLDOl 4 


61 


3D 


" 


SLDOl 5 


62 


3E 


" 


SLD016 


63 


3F 


" 


SLLA1 


96 


60 


Shor 


SLLA2 


97 


61 


" 


SLLA3 


98 


62 


" 


SLLA4 


99 


63 


" 



Short Load Local 



Short Load Global 



Short Load Local Address 
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SLLA5 


100 


64 


" 


n n n 


SLLA6 


101 


65 


" 


n ■ n 


SLLA7 


102 


66 


m 


n n n 


SLLA8 


103 


67 


n 


* n ii 


SL0D1 


173 


AD 


Short 


Load Intermediate 


SLOD2 


174 


AE 


" 


ii ii 


SPR 


209 


Dl 


Store 


Processor Register 


SRO 


165 


A5 


Store 


Global 


SRS 


188 


BC 


Subrange Set 


SSTL1 


104 


68 


Short 


Store Local 


SSTL2 


105 


69 


n 


h n 


SSTL3 


106 


6A 


" 


H ■ 


SSTL4 


107 


6B 


n 


n n 


SSTL5 


108 


6C 


M 


" " 


SSTL6 


109 


6D 


" 


n n 


SSTL7 


110 


6E 


" 


It n 


SSTL8 


111 


6F 


■ 


H n 


STB 


200 


C8 


Store 


Byte 


STE 


217 


D9 


Store 


Extended 


STL 


164 


A4 


Store 


Local 


STH 


142 


8E 


Store 


Multiple 


STO 


196 


C4 


Store 




STP 


202 


CA 


Store 


Packed 


STR 


166 


A6 


Store 


Intermediate 


STPL 


244 


F4 


Store 


Real 


SWAP 


189 


BD 


Swap 




TJP 


241 


Fl 


True . 


Jump 


TNC 


190 


BE 


Truncate Real 


UJP 


138 


8A 


Unconditional Juirp 


USPL 


139 


8B 


Unconditional Jump Long 


UNI 


219 


DB 


Set Union 


WAIT 


223 


DF 


VTait 




XJP 


214 


D6 


Case , 


Jump 



A-6 



0400101:0AA 



APPENDIX B 

P-MACHINE OPCODES 

(Numeric Order) 



B££ fleje Opcode 




1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 



00 
01 
02 
03 
04 
05 
06 
07 
08 
09 
0A 
0B 
0C 
0D 
0E 
OF 
10 



13 

14 
15 
16 
17 
18 



IB 
1C 



20 
21 
22 
23 
24 
25 
26 
27 



2A 
2B 



2E 
2F 
30 
31 
32 
33 
34 
35 
36 



SLDC0 

SLDC1 

SLDC2 

SLDC3 

SLDC4 

SLDC5 

SLDC6 

SLDC7 

SLDC8 

SLDC9 

SLDC10 

SLDC11 

SLDC12 

SLDC13 

SLDC14 

SLDC15 

SLDC16 

11 SLDC17 

12 SLDC18 
SLDC19 
SLDC20 
SLDC21 
SLDC22 
SLDC23 
SLDC24 

19 SLDC25 
1A SLDC26 
SLDC27 
SLDC28 
ID SLDC29 
IE SLDC30 
IF SLDC31 
SLDL1 
5LDL2 
SLDL3 
SLDL4 
SLDL5 
SLDL6 
SLDL7 
SLDL8 

28 SLDL9 

29 SLDL10 
SLDL11 
SLDL12 

2C SLDL13 

2D SLDL14 

SLDL15 

SLDL16 

SLDOl 

SLD02 

SLD03 

SLD04 

SLD05 

SLD06 

SLD07 



Description 

Short Load Constant 



Short Load Local 



Short Load Global 
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55 37 SLD08 " 

56 38 SLD09 " " 

57 39 SLD010 ... 

58 3A SLDOll " " " 

59 3B SLD012 " " 

60 3C SLD013 " " 

61 3D SLD014 ...» 

62 3E SLD015 " " " 

63 3F SLD016 " 

64 40 unused 

95 5F 

96 60 SLLA1 Short Load Local Address 

97 61 SLLA2 " ■ " 

98 62 SLLA3 ... 

99 63 SLLA4 ... 

100 64 SLLA5 ... 

101 65 SLLA6 ... . 

102 66 SLLA7 ... 

103 67 SLLA8 ... 

104 68 SSTL1 Short Store Local 

105 69 SSTL2 

106 6A SSTL3 ... 

107 6B SSTL4 ... 

108 6C SSTL5 ... 

109 6D SSTL6 ... 

110 6E SSTL7 ... 

111 6F SSTL8 ... 

112 70 SCXG1 Short Call External Global 

113 71 SCXG2 ... 

114 72 SCXG3 ... 

115 73 SCXG4 ... . 

116 74 SCXG5 . . . 

117 7 5 SCXG6 ... 

118 76 SCXG7 ... 

119 77 SCXG8 ... 

120 78 SIND0 Short Index 

121 79 SIND1 

122 7A STND2 

123 7B SIND3 

124 7C SIND4 " " 

125 7D SIND5 

126 7E SIND6 

127 7F SIND7 " " 

128 80 LDCB Load Constant Byte 

129 81 LDCI Load Constant Integer 

130 82 LCO Load Contant Offset 

131 83 LDC Load Word Constant 

132 84 LLA Load Local Address 

133 85 LDO Load Global 

134 86 LAO Load Global Address 

135 87 LDL Load Local 

136 88 LDA Load Intermediate Address 

137 89 LOD Load Intermediate 

138 8A UJP Unconditional Jump 

139 8B UJPL Unconditional Jump Long 

140 8C MPI Multiply Integer 

141 8D DVI Divide Integer 

142 8E STH Store Multiple 

143 8F MODI Modulo Integers 

144 90 CLP Call Local Procedure 

145 91 CGP Call Global Procedure 

146 92 CIP Call Intermediate Procedure 

147 93 CXL Call External Local 
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148 


94 


CXG 


149 


95 


CXI 


150 


96 


RPU 


151 


97 


CFP 


152 


98 


LDCN 


153 


99 


LSL 


154 


9A 


LDE 


155 


9B 


LAE 


156 


9C 


NOP 


157 


9D 


LPR 


158 


9E 


BPT 


159 


9F 


BNOT 


160 


A0 


LOR 


161 


Al 


LAND 


162 


A2 


AD I 


163 


A3 


SBI 


164 


A4 


STL 


165 


A5 


SRO 


166 


A6 


STR 


167 


A7 


LDB 


168 


A8 


NAT 


169 


A9 


NAT-INFO 


170 


AA 




171 


AB 


CAP 


172 


AC 


CSP 


173 


AD 


SLOD1 


174 


AE 


SLOD2 


175 


AF 




176 


BO 


EQUI 


177 


Bl 


NEQI 


178 


B2 


LEQI 


179 


B3 


GEQI 


180 


B4 


LEUSW 


181 


B5 


GEUSW 


182 


B6 


EQPWR 


183 


B7 


LEPWR 


184 


B8 


GEPWR 


185 


B9 


EQBYT 


186 


BA 


LEBYT 


187 


BB 


GEBYT 


188 


BC 


SRS 


189 


BD 


SWAP 


190 


BE 


TNC 


13i 


BF 


RND 


192 


CO 


ADR 


193 


CI 


SBR 


194 


C2 


MPR 


195 


C3 


DVR 


196 


C4 


STO 


197 


C5 


MOV 


198 


C6 


DUPR 


199 


C7 


ADJ 


200 


C8 


STB 


201 


C9 


LDP 


202 


CA 


STP 


203 


CB 


CHK 


204 


CC 


FLT 


205 


CD 


EQREAL 


206 


CE 


LEREAL 


207 


CF 


GEREAL 


208 


DO 


LDM 


209 


Dl 


SPR 


210 


D2 


EFJ 


211 


D3 


NFJ 



Call External Global 

Call External Intermediate 

Return from Procedure 

Call Forms 1 T>rn/*AA,,m 

Load Constant NIL 

Load Static Link 

Load Extended 

Load Extended Address 

No Operation 

Load Processor Register 

Break point 

Boolean Not 

Logical Or 

Logical And 

Add Integer 

Subtract Integer 

Store Local 

Store Global 

Store Intermediate 

Load Byte 

Enter Native Code 

Native Code Information 

reserved 

Copy Array Parameter 

Copy String Parameter 

Short Load Intermediate 

it « n 

unused 

Equal Integer 

Not Equal Integer 

Less Than or Equal Integer 

Greater Than or Equal Integer 

Less Than or Equal Unsigned 

Greater Than or Equal Unsigned 

Equal Set 

Less Than or Equal Set 

Greater Than or Equal Set 

Equal Byte Array 

Less Than or Equal Byte Array 

Greater Than or Equal Byte Array 

Subrange Set 

Swap 

Truncate Real 

Round Real 

Add Real 

Subtract Real 

Multiply Real 

Divide Real 

Store 

Move 

Duplicate Real 

Adjust Set 

Store Byte 

Load Packed 

Store Packed 

Check Subrange Bounds 

Float 

Equal Real 

Less Than or Equal Real 

Greater Than or Equal Real 

Load Multiple 

Store Processor Register 

Equal False Jump 

Not Equal False Jump 
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212 D4 FJP False Jump 

213 D5 FJPL False Long Jump 

214 D6 XJP Case Jump 

215 D7 IXA Index Array 

216 D8 IXP Index Packed Array 

217 D9 STE Store Extended 

218 DA INN Set Membership 

219 DB UNI Set Union 

220 DC INT Set Intersection 

221 DD DIF Set Difference 

222 DE SIGNAL Signal 

223 DF WAIT Wait 

224 E0 ABI Absolute Value Integer 

225 El NGI Negate Integer 

226 E2 DUP1 Duplicate One Word 

227 E3 ABR Absolute Value Real 

228 E4 NGR Negate Real 

229 E5 LNOT Logical Not 

230 E6 IND Index 

231 E7 INC Increment 

232 E8 EQSTR Equal String 

233 E9 LESTR Less Than or Equal String 

234 EA GESTR Greater Than or Equal String 

235 EB ASTR Assign String 

236 EC CSTR Check String Index 

237 ED INCI Increment Integer 

238 EE DECI Decrement Integer 

239 EF SCPI1 Short Call Intermediate Procedure 

240 F0 SCPI2 " 

241 Fl TJP True Jump 

242 F2 LDCRL Load Constant Real 

243 F3 LDRL Load Real 

244 F4 STRL Store Real 

245 F5 unused 

249 F9 

250 FA RESERVE1 reserved 

251 FB RESERVE2 " 

252 FC RERERVE3 " 

253 FD RESERVE4 " 

254 FE RESERVE5 " 

255 FF RESERVE6 " 
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P-MACHINE INTRINSICS 



Kernel procedures provided in the p-machine 
emulator. 



1 - reserved 

2 - ■ 

3 - 

4 - Procedure RELOCSEGt seg_erec;erec_p ); 

5 - reserved 

6 - 

7 - 

8 - 

9 - 

10 - ■ 

11 - 

12 - " 

13 - 

14 - Procedure HOVESEG< seg_sib:sib_p; src_pool:poolptr; src_off set :memptr ); 

15 - Procedure MOVELEFT{ var source:bytearray; var dest :bytearray; 

n_bytes: integer ) ; 

16 - Procedure HOVERIGHT( var source:bytearray; var dest :bytearrayj 

n_bytes : integer ) ; 

17 - reserved 

18 - Procedure UNlTREADf unit mnitnum; var buff :bytearray ; 

n_bytes, block t control : integer; 

19 - Procedure DNITWRITE t unit zunitnum; var buff rbytearray; 

n_bytes, block, control: integer; 

20 - Procedure TIME( var hi_word, lo_word: integer ); 

21 - Procedure FILLCHARt var dest:bytearray; n_bytes, value:integer ); 

{The SCAN parameters shown here do not match those in an actual SCAN call: 
the Pascal compiler generates the appropriate parameters.} 

22 - Function SCAN( disp: integer ; not_equal:boolean; target :byte; 

var a;bytearray; start_index, mask: integer ): 

23 - Procedure IOCHECK; 

24 - Procedure GETPOOLBYTES ( var dest ;bytearray; pooldesc:poolptr ; 

pooloffset:memptr ; nbytes: integer ) ; 

25 - Procedure PUTPOOLBYTES ( source:bytearray; pooldesc:poolptr ; 

pooloffset:memptr ; nbytes: integer ) ; 

26 - Procedure FT.TPsgGBYTES ( seg_erec?erec n* ?eo_of f set ; n_wordst integer ) ; 

27 - Procedure QUIET; 

28 - Procedure ENABLE; 

29 - Procedure ATTACH ( sem:sem_p; vector : integer ); 

30 - Function IORESULT: integer ; 

31 - Function UNITBUSY( unitsunitnum ):boolean; 

32 - Function POWEROFTEN( arg:integer ):real; 

33 - Procedure 0NITWAIT< unit :unitnum ); 

34 - Procedure UNITCLEAR{ unit mnitnum ); 

35 - reserved 

36 - Procedure UNITSTATUS C unitrunitnum; var stat_rec:status_rec ; 

controliinteger ) ; 

37 - Procedure IDSEARCH ( var symcursor isymrec; var buffer :bytearray ) ; 

38 - Function TREESEARCH( root :treerec_p; var node:treerec; 

namesalpha ):integer; 

39 - Function READSEG( seg_erec:erec_p ):integer; 



0400101:0AA A-ll 



APPENDIX D 
PASCAL DEFINITIONAL RSP 



Unit Globals; 

Interface 

Uses t$u opsys:kernel.code} kernel ( (types) syscomrec, bytearray ); 

Type syscom_ptr=*syscomrec; 

statrec=array [0. .29] of integer; 
statctrl=packed record 

io_directions (output_status, input_status) ; 
reserved:array{l . .12] of boolean; 
user_defined:arraytl3..15J of boolean; 
end; 
rwctrl=packed record 

async:boolean; 
physsect : boolean ; 
no_spec : boolean ; 
no_cr 1 f : boo lean ; 

reserved:array [4..12] of boolean; 
user_def ined:array[13. .15] of boolean; 
end; 
word_array=arraylO..O] of integer; 
chac_array=packed array [0..0] of char; 
p_memory=record case integer of 



); 



i: integer 
( c:char ) ; 
( pb:*byte_ar ray ); 
( pw:~word_array >; 
( pc:"char_array ); 



0: 
1: 
2: 
3: 
4: 
end; 
disk_inforec=record 

tracks_per_disk : integer ; 

sectors_per_track: integer ; 

bytes_per_sector : integer ; 

interleave: integer; 

f irst_pascal_track: integer ; 

track_skew: integer; 

eiiu tuiak_ini0ieij}; 

Procedure PME_Signal„Event ( event_num: integer ); 
Procedure PKE_Got_Break ; 

Implementation 

End {Globals}. 

{ST PASCAL DEFINITIONAL RUN-TIME SUPPORT PACKAGE J 

{$[)-} 

{$D ASYNCHRONOUS-} 

Unit RSP; 

Interface 

Uses {$U opsys:kernel.code} kernel ( { const } DLE, 

{ types > iorsltwd, 
bytearray, full_address, 
unitnum, u table, syscomrec, 
{ vars } syscom ) , 
{SU globals. code} globals; 

Procedure UNITCLEAR( unit_no:unitnuni ); 

Procedure UNTTSTATUS ( unit_no:unitnum; var status:statrec; control:statctrl ) ; 
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{Buffer parameter declarations for UNITREAD ana UNITWRITE, below, do not 
reflect the way Pascal programs use these procedures. In an actual 
call, the Pascall compiler generates the appropriate parameters. The 
byte-pointer has been separated into two parameters so that the RSP 
can handle them individually.} 

Procedure ONITREAD( unit_no:unitnum; buffer:p_roemory; index: integer ; 
length:integer; block: integer; control:rwctrl ); 
Procedure DNITWRITE( unit_no:unitnum? buf fer :p_jnemory; index: integer; 

length; integer; block: integer ; controlrrwctrl ); 
Procedure SYSREAD( unit_no:unitnum; buf fer :p_memory; index: integer ; 

length: integer ; block : integer ; control : rwctrl j 

codepool:full_address ); 
Function UNITBUSYt unit_no:unitnum ):boolean; 
Procedure UNITWAITt unit_no;unitnum ); 
Function IORESULT:iorsltwd; 
Procedure IOCHECK; 
Procedure QUIET; 
Procedure ENABLE; 
Procedure TIME ( var hiword, loword: integer ); 

{$P} 
Implementation 

{Note that actual calls to the bios are between two assembly language routines 
and parameters may not be passed as in pascal procedures, in particular 
parameters and results are often in registers. } 

Oses {$u bios. code) BIOS; 

Const max_char_vols=29; { console, printer , remote & 26 serial vols } 
lf=10; {ASCII linefeed) 

cr=13; {ASCII carriage return} 

Type unit_types=tbad, sys,con,dsk r prn,rem,ser ,usr) ; 
°P_types=(read_op,write_op,init_op,status„op) ; 

Var event_ccdc:p_Eiemory; {filled in by interpreter} 
break_code:p_memory; (filled in by interpreter} 
alpha_locked:packed array II. .max_char_vols] of boolean; 
dle_rcvd:packed array[l, .max_char_vols] of boolean; 
{$P} 
Function Translate! unit_no:unitnum; operation:op_types; 

var block : integer ; var blockedrboolean; var device: integer; 
var flags:integer; var u_type:unit_types ):iorsltwd; 

procedure trans_err( err:iorsltwd ); 
begin 

translate:=err; 

u_type:=bad; 

exit (translate) ; 
end; 

begin 

{ if an error occurs in translate then u_type will be "bad" and 

the function result will indicate what error occurred. } 
u_type:=bad; 
translate :=*i_no_error ; 
if unit_no<=8 
then begin 

device: =0; 
case unit_no of 
0: u_type:=sys; 
1 f 2 : u_type : =con ; 
3: trans_err( i_bad_unit ); 
4,5: begin 
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u_type:=dsk; 
device :=unit_no-4; 
end; 
6: u_type:=prn; 

7: if operation=write_op {remin) 
then trans_err( i_bad__mocle ) 
else u_type:=rem; 
8: if operation=read_op {remout} 
then trans_err( i_bad_mode ) 
else u_type:=rem; 
end (case) ; 
end 
else if unit_no<<syscom".subsidstart> 
then begin 

u_type:=dsk; 
device :=unit_no-9+2; 
end 
else if unit_no<(syscom".subsidstart + 

sy scorn*. unitdi vis ion. subsidmax) 
then with syscom*.unitable~ [unit_no] do 
begin 

if ueovblk=0 then trans_err{ i_no_unit ); 

if block >=ueovblk then trans_err( i_ill__block 

u_type:=dsk; 

uni t_no : =uphysvol ; 

if unit_no>=9 then device:=unit_no-9+2 

else device :=unit_no-4 ; 
block : =block+ublkoff ; 
translate :=i_no_error; 
end 
else if unit_no<(syscom".subsidstart+ 

sy scorn" . unitdivision . subsidmax+ 
sy scorn". unitdi vision . serialmax) 
then begin 

u_type:=ser ; 

device :=unit_no-(syscoin" . subsidstart+ 

syscom". unit division. subsidmax) ; 
end 
else if unit_no>=128 
then begin 

u_type:=usr; 
device :=unit_no-128; 
end 
else trans_err( i_bad_unit ); 
blocked:=u_type in [sys,dsk,usr] ; 
case u_type of 
con: f lags:=l ; 

prn: f lags:«3 ; 
ser: flags :=4+dev ice; 
end {case}; 
end {translate} ; 

{SPI 

Procedure UNITREADC unit_no;unitnum; buffer :p_memory; index: integer ; 
length: integer; block : integer ; control : rwctrl }; 
var stack_addr :f ulladdress; 
begin 

stack_addr [03 :=0; 

stack_addrfll:=0; 

SYSREADf unit_no, buffer, index, length, block, control, stack_addr ) ; 
end {UNITFEAD); 

Procedure SYSREAD{ unit_no:unitnum; buf fer :p_memory ; index: integer; 
length: integer; block: integer ; control: rwctrl ? 
codepool:f ulladdress } ; 
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ar device,f lags: integer; 
blocked : boolean ; 
u__type : un i t_types ; 
iorslt : ior sltwd ; 

Function Char_ln: iorsltwd; 
label 100; 
var ch:char; 

iorslt: iorsltwd? 

Procedure check_result ; 
begin 

if iorslt<>i_no_error 
then begin 

char_in:=iorslt; 
exit (char_in) ; 
end; 
end {check_resultl; 

procedure echo_char ( ch:char ); 
begin 

iorslt:=bios_con_write( ch ); 
check_result; 

if (ch=chr(cr)) and (not control. no_crlf) 
then echo_char( chr(lf) ); 
end (echo_char }; 

begin 

while length>0 do 
begin 

case u_type of 

con: iorslt:=bios_con_read( ch ); 
prn: iorslt:=bios_prn_read{ ch ); 
rem: iorslti=bios_rem__read( ch ); 
ser: iorslt:=bios_ser_read ( device, ch ); 
end; 

check_result; 

if not control. no_spec then 
begin 

if ch=syscom*.crtinfo.eof 
then begin 

if unit_no=l 

then fillchar( buf fer .pc* [index] , length, chr(0) ) 
else buf fer. pc A [index] :=ch; 
exit (char_in) ; 
end; 
if ch=sysconT.crtinfo.a]phalok 
then begin 

alpha_locked[flags] :=not alpha_locked[f lags] ; 
goto 100; 
end; 
end {not no_5^ec}; 
if alpha_locked[ flags] 
then if ch in [ 

then ch:=chr( ord(ch)-32 ); 
if unit_no=l then echo_char( ch ); 
buffer. pc~[index] :=ch? 
index :=index+l; 
length :-length-l; 
100: 
end {while length>0>; 
char_in:=iorslt; 
end {char_inj ; 
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begin 

syscom~.iorslt:-translate( unit_no r read_op, block, blocked, 

device, flags, u_type )j 
if syscom A .iorslt<>i_no_error then exit (SYSREAD) ; 
if blocked 

then case u_type of 

sys: sysconT.iorslt:*bios_sys_read< block, length, buffer, index, 

device, control ) ; 
dsk: sysconT. iorslt :=bios_dsk_read( block, length, buffer, index, 

device, control, codepool ) ; 
usr: syscom".iorslt:=bios_usr_read< block, length, buffer, index, 

device, control ) ; 
end {case} 
else sy scorn" . iorslt :=char_in; 
end (SYSREAD); 

{?P> 

Procedure [JNITWBXTfcf unit_no:unitnum; buffer :p_memory; index: integer ; 

length: integer ; block: integer; control:rwctrl J; 
var device, flags: integer; 

blocked: boolean; 

u_type:unit_types; 

iorslt:iorsltwd; 

Function Char_Out riorsltwd; 
var ch:char ; 

iorslt: iorsltwd; 

i: integer; 

Procedure check_result ; 
begin 

if iorsltoi_no_error 
then begin 

char_out:=iorslt; 
exit (char_out) ; 
end; 
end {check_resultj ; 

Procedure Send_Char( ch:char ); 

begin 

case u_type of 

con: iorslt:=bios_con_write t ch ) ; 

prn: iorslt :=bios_prn_write ( ch ); 

rer«: iorslt:=bios_rem_write ! ch ); 

ser: iorslt :«*bios_ser_wr it e ( device, ch ) ; 
end; 

cneck_resuit ; 
if <ch=chr(cr)> and (not control. no_crlf) 

then send_char( chr(lf) ); 
end (send_char J ; 

begin 

while length>0 do 
begin 

ch:=buf fer .pc" [index! ; 
if control. no_spec 
then send_char( ch ) 
else if dle_rcvd[flagsj 
then begin 

for i:=l to ord(ch)-32 do send_char ( 
dle_rcvdlf lagsl :=false; 
end 
else if ch=chr(dle) 

then dle_rcvd[flags] :*true 
else send_char( ch ); 
index:=index+l; 
length :=length-l; 
end {while length>0J; 
char_out :=iorslt; 
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end {char_out} ; 

begin 

syscom*. iorslt :=transiate £ unit_.no , write_op, block, blocked, 

device, flags, u_type ); 
if syscom*. iorslt<>i_no_error then exit (UNITWRITE) ; 
if blocked 

then esse u_type of 

sys: sysconT, iorslt :=bios_sys_write( block, length, buffer, index, 

device, control ) ; 
dsk : syscom* .iorslt : =bios_dsk_wr ite ( block , length , buffer , index, 

device, control ) ; 
usr : syscoai* .iorslt : =bios_usr_vr ite ( block , length , buffer , index, 

device, control ) ; 
end {case} 
else sy scorn*, i or sit :*=char_out ; 
end {UNITWRITE}; 

{$P> 

Procedure UNITCLEAR{ unit_no:unitnum 1; 
var block, device, flags: integer; 
blocked: boolean ; 
u_type : un i t_types ; 
begin 

syscom*. ior sit :=translatet unit_no, init_op, block, blocked, 

device, flags, u_type ) ; 
if sysconT. iorsltoi_no_error then exit CUNITCLEAR) ; 
case u_type of 

sys: syscom* .iorslt:=bios_sys_init ( device, PME_signal_event ) ; 
con: syscom".iorslt:=bios_con_init ( PME_got_break, syscom ); 
dsk: syscom*. iorslt:=bios_dsk_init ( device ); 
prn: syscom" . iorslt :=bios_prn_init; 
rem: syscom*. ior si t:=bios_rem_init; 
ser: syscom*. iorslt:=bios_ser_init ( device ); 
usr: syscom". iorslt;=bios_usr_init ( device ); 
end {case}; 
if not blocked 
then begin 

alpha_locked [flags] :-false; 
dle_rcvd[f lags] :=false; 
end; 
end {UNITCLEAR}; 



{$P} 

Procedure UNITSTATUS { unit__no:unitnum; var status:statrec; control:statctrl }; 
var block, device, flags: integer ; 
blocked: boolean; 
u_type:unit_types; 
begin 

syscom*. ior sit :*trans late t unit_no, status_op, block, blocked, 

device, flags, u_type ) ; 
if syscom", iorsltoi_no_error then exit (UNITSTATUS) ; 
case u_type of 

sys: syscom". iorslt :=bios_sys_stat ( status, control ); 
sysconT. ior si t:=bios_con_stat ( status, control ) ; 
syscom*. iorslt;=bios__dsk_stat ( device, status, control ) ; 
syscom* ,iorslt:=bios_prn_stat t status, control ); 
syscom*. iorslt:=bios_rem_stat( status, control ); 
syscom*. iorslt:=bios_ser_stat£ device, status, control ); 
syscom*. iorslt:=bios_usr_stat ( device, status, control ); 



con: 
dsk: 

prn: 
rem: 
ser : 
usr : 



end {case}; 
end {DNITSTATUS}; 
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(SPl 

Function DNITBUSY{ unit_no:unitnum ) iboolean) ; 

var in_status, 

out_status: statrec; 
control_word: statctrl; 
begin 

{SB ASYNCHRONOUS*} 

control_word.io_direction:=input_status; 

unitstatust unit_no r in_status, control_word ); 

control_word.io_directipn:=output_status; 

unitstatusf unit_no r out_status, control_word ); 

unitbusy:= (in_status[D] <>0) or (out_statusIOJ <>0) ; 

{$E ASYNCHRONOUS*} 

{SB ASYNCHRONOUS-} 

unitbusy: -false; 

($E ASYNCHRONOUS-} 
end IUNITBUSY} ; 

Procedure UNITWAIT{ unit_no:unitnum }; 
var in_status, 

out_status: statrec; 
in_ctrl_word, 
out_ctrl_word: statctrl; 
begin 

{$B ASYNCHRONOUS*} 

in_ctrl_word. io_direction:=input_status; 

out_ctrl_word.io_direction:=output_status; 

repeat 

unitstatus< unit_no, in_status, in_ctrl_word ),* 
unitstatus( unit_no, out_status, out_ctrl_word ); 
until (in_status[0]=0) and <out_status[ul=0) ; 
{$E ASYNCHRONOUT+} 
(SB ASYNCHRONOUS-} 

{unitwait does nothing on synchronous systems} 
{$E ASYNCHRONOUS-! 
end {UNITWAIT}; 

{$P} 

Function IORESULT{ : iorsltwd) ; 
begin 

ioresult:=sy scorn" .iorslt; 
end {IORESULT}; 

Procedure IOCHECK; 
begin 

if syscom*.iorslt<>i_no_error then { exec_errort 10 ) }; 
end {IOCHECK}; 

Procedure QUIET; 
begin 

bios_quiet; 
end {QUIET}; 

Procedure ENABLE; 
begin 

bios_enable; 
end {ENABLE}; 

Procedure TIME{ var hiword, lowordiinteger }; 
Var status; statrec; 

control: statctrl; 
begin 

UNITSTATUS CO, status, control) ; 

loword:=status[lJ ; 

hiword:=status[2] ; 
end {TIME}; 

End {RSP>. 
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{ST PASCAL DEFINITIONAL BASIC INPUT/OUTPUT SYSTEM ) 
(SU-1 

Unit BIOS; 

Interface 

Uses {$u opsys:kernel.code} KERNEL* { types } full_address, bytearray, 

iorsltwd, syscomrec ) , 
I5u globals.code} globals; 

Var curform:disk_inforec; {initialized by bootstrap} 

sect_per_block: integer; {initialized by bootstrap} 

hi_addr:p_memory; {initialized by bootstrap} 

sector_buffer:p_memory; {initialized by bootstrap} 

sect_trans:p_memory; {initialized by bootstrap} 

Function bios_con_read( var ch:char ):iorsltwd; 

Function bios_con_write ( chtchar ): iorsltwd; 

Function bios_con_init ( procedure got_break; syscom:syscom_ptr ):iorsltwd; 

Function bios_con_stat ( var status:statrec; controlrstatctrl ):iorsltwd; 

Function bios_prn_read( var ch:char ):iorsltwd; 

Function bios_prn_write ( ch:char Jriorsltwd; 

Function bios_prn_init riorsltwd; 

Function bios_prn_stat < var status:statrec; control :statctrl ): iorsltwd; 

Function bios_dsk_read( block: integer; length: integer; buffer :p_jnemory; 

index, drive:integer ; control irwctrl; 

codepool:fulladdress ) :iorsltwd; 
Function bios_dsk_write ( block: integer ; length: integer ; buffer :p_jnemory; 

index, drive: integer ; controlrrwctrl ) riorsltwd; 
Function bios_dsk_init < drive: integer ) riorsltwd; 
Function bios_dsk_stat ( drive:integer ; var status:statrec; 

control:statctrl ):iorsltwd; 

Function bios_rem_read ( var ch:char ):iorsltwd; 

Function bios_rem_write { ch:char ) riorsltwd; 

Function bios_rem_init:iorsltwd; 

Function bios_rem_stat ( var status:statrec; controlrstatctrl ):iorsltwd; 

Function bios_usr_read( block: integer r length:integerj buffer ?p_merncry* 

index, device: integer ; controi:rwctrl ):iorsltwd; 

Function bios_usr_write{ blockrinteger; length: integer; buffer :p_memory; 
index, device: integer; control:rwctrl ): iorsltwd; 

Function bios_usr„init ( device: integer ): iorsltwd; 

Function bios_usr_stat ( devicerinteger; var status rstatrec; 
controlrstatctrl ):iorsltwd; 

Function bios_sys_read ( block:integer; length : integer ; buffer :p_memory; 

index, device: integer; control rrwctrl ) : iorsltwd; 

Function bios_sys_write( block : integer ; length: integer ; buf ferrp_memory; 

index, device: integer; control:rwctrl ):iorsltwd; 
Function bios_sys_init ( device: integer; 

procedure signal_event ( event_num: integer ) ) riorsltwd; 
Function bios_sys_stat ( var status:statrec; control:statctrl ):iorsltvd; 

Procedure bios_quiet; 
Procedure bios_enable; 

Function bios_ser_read( device: integer ; var ch:char ):iorsltwd; 
Function bios_ser_writeC device: integer ; ch:char ):iorsltwd; 
Function bios_ser_init { device: integer >:iorsltwd; 
Function bios_ser_stat t device: integer ? var status:statrec; 
control:statctrl ):iorsltwd; 
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Procedure disk_change< var newform:disk_inforec ); {called by bootstrap} 

Implementation 

Uses {$u sbios.code} SBIOS; 

Const q_size-64; 
q_empty=0; 

bell=7; 

Type q„rec=record 

bottom, top: integer ; 
iorsltiiorsltwd; 
ringbell: boolean; 

data:packed array [1. .q_size] of char; 
end; 

Var save_syscom_ptr :syscom_ptr ; 

{ save_break_proc: procedure; } {can 
f lush_f lag, stop_f lag: boolean; 

con_queue : q_rec ; 
prn_queue:q_rec; 
rem_queue:q_rec; 

Procedure pollunits; forward; 

Procedure q_init ( var q:q_re,c ); 
begin 

{set up empty queue} 

q. bottom :=q_size; 

q . top: =q_empty ; 

q. iorslt:=i_noerror j 
end {q_init}; 

Function q_count ( q:q_rec ):integer; 
begin 

if q.top>q.bottost then q__count:=q.top-q. bottom 

else q_count:=q_size-q.bottom+q.top; 
end (q_countl; 

Function q_get ( var q:q_rec ):char; 
begin 
repeat 

pollunits; 
until q_count{ q )>0; 
if q.bottom=q_size 
then q.Dottoms«=l 
else q.bottoro:=q.bottom+l; 
q_get : «q. data tq. bottom] ; 
if q.bottora=q.top then q_init( q }; 
end (q_get); 

Procedure q_put t var q:q_rec; ch:char ); 

var old_top: integer; 

begin 

o ld_top : =q . t op ; 
if q.top*q_size 
then q.top:=l 
else q.top:»q.top+l; 
if q.top»q. bottom 

then begin {overflow} 
q.top:=old_top; 
if q.ringbell 

then q.iorslt:=conwrit ( chr(bell) ); 
exit (qjput) ; 
end; 
q.dataCq.top] s«ch; 
end {q_put}; 

Procedure pollunits; 
var char_rdy:boolean; 
ch:char ; 
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Function special_char ( var ch:char Jsboolean; 

{only used on console) 

begin 

with save_syscom_ptr*.crtinfo do 
begin 

speciai_char :=true; 
ch:=chr(ordt odd(ordCch)) and 

odd (ord{char_inaslO ) ) ) ; 
if ch*-break 
then begin 

{call save_break_pcoc} 
stop_flag:=false; 
flush_flag:=false; 
end 
else if ch*stop 

then stop_f lag:=not stop_flag 
else if ch=flush 
then begin 

flush_flag:=not flush_flag; 
stop_flag:=false; 
end 
else special_char :=false; 
end; 

end {special_char}; 

begin 

with con_queue do 
begin 

iorslt:=constat ( char_rdy ); 
if char_rdy and {iorslt=i_noerror) 
then begin 

iorslt :=conread( ch ); 
if iorslt»i_noerror 

then if not special_char { ch ) 

then q_put( con_queue, ch J; 
end; 
end; 
with prn_queue do 
begin 

iorslt:=prnstat ( char_rdy ); 
if char_rdy and (iorslt=i_noerror) 
then begin 

iorslt:-prnread( ch ); 
if iorslt=i_noerror 

then q_put ( prn_queue, ch ); 
end; 
end; 
with renuqueue do 
begin 

iorslt :=remstat{ char_rdy ); 
if char_rdy and (iorslt=i_noerror) 
then begin 

iorslt :=remread( ch ) ; 
if iorslt=i_noerror 

then q_put( rem_queue, ch ); 
end; 
end; 
end {pollunits}; 

Function bios_con_read{ var ch:char ):iorsltwd); 

begin 

flush_f lag:=false; 

stop_flag:=false; 

ch:=q_get( con_queue 3; 

bios_con_read;s=con_queue. iorslt; 
end; 
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Function bios_con_write{ ch:char ) : iorsltwd} ; 
begin 

bios_con_write:=i_no_error ; 
repeat 

pollunits; 

if flush_flag then exit (bios_con_write) ; 
until stop_f lag=false; 
bios_con_write:=conwrit ( ch ); 
end; 

Function bios_con_init{ procedure got_break; syscom:syscom_ptr Jsiorsltwd}; 
begin 

{ Note: the address of got_break procedure should be saved at this point, 
this cannot be shown in Pascal; however, the following describes what is 
actually done in a bios: 

save_break_proc:= got_break; } 

save_syscoin_ptr :=syscom; {save syscom pointer} 

flush_f lag: "false; 

stop_f lag:=false; 

q_init( con_queue ); 

con_queue.ringbell:=true; 

bios_con_init:=coninit; 
end; 

Function bios„con__stat{ var status :sta tree; control tstatctrl ) : iorsltwd) ; 
begin 

pollunits; 

if control. io_direction=input_status 
then statusIO] :=q_count ( con_queue ) 
else statusIO] :=0; 
bios_con_stat i =con_queue . ior sit j 
end; 

Function bios_pm_read{ var ch:char J : iorsltwd} ; 
begin 

ch:=q_get( prn_queue ); 

bios_prn„read : =prn_queue . ior sit ; 
end; 

Function bios_prn_write{ chrchar >: iorsltwd} ; 
begin 

pollunits; 

bios_prn_write: -prnwr it ( ch ); 
end; 

Function bios_prn_init { : iorsltwd} ; 
begin 

q_init( prn_queue ); 

prn_queue.ringbell:=false; 

bios_prn_init :=prninit ; 
end; 

Function bios_prn_stat{ var status:statrec; control:statctrl ):iorsltwd}; 
begin 

pollunits; 

if control . io_direction"input_status 
then statusIO] :=q_count ( prn_queue ) 
else statusIO] :=0; 
bios_prn_stat :=prn_queue. ior sit ; 
end; 

Procedure disk_change£ var newforni:disk_inforec 1; 

const blksize=512; 

var phys_sector ,logic_sector , try it : integer ; 

used:boolean j 
begin 

curforni:=newform; 

sect_per_block :=blksize div curforrr.bytes_per_sector ; 
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{initialize sector_translation table) 
phys_sector : =0 ; 

for logic_sector :=0 to curform. sectors__per_track-l do 
begin 

if phys_sector >=cur form. sector s_per_t rack 

then phys_sector :=phy s_sector-cur form. sector s_per_t rack; 
used:-false; 
for tryit:=0 to logic_sector-l do 

if sect_trans.pb*[tryit)=phys_sector then used:=true; 
if used then phys_sector:=phys_sector+l; 
until not used; 

sect_trans.pb*Elogic_sector] :=phys_sector ; 
phys_sector:=phys_sector+cur form. interleave; 
end; 
end {disk_change) ; 

Punction disk_rw( block: integer; length: integer; buffer :p_memory ; 
index , dr i ve : int ege r ; con t r o 1 : rwct r 1 ; 
baseaddr ifulladdress; read_disk: boolean ) : iorsltwd; 
label 10,99; 
const max_retry=5; 
var partial: boolean; 

retry r rel_sector ,logic_sector ,iogic_t rack, skew, 

sector , track : integer ; 

stackbase: f ulladdress ; 

iorsltriorsltwd; 

procedure calc_sect; 

{calculate physical sector address from logical sector address) 

begin 

sector :={ (sect_trans.pb* Ilogic_sector I+skew) mod 
curform. sector s_per_t rack )+l; 
end; 

procedure convert; 

{convert block parameter to track and sector address} 

begin 

if control .physsect 
then begin 

length: =curform.bytes_per_sector ; 
track:=block div curform. sectors_per_track; 
sector :=(block mod curform. sectors_per_track) +l; 
end 
else begin 

rel^sector :=block*sect_per_block; 

logic_track :=rel_sector div curform. sectors_per_track; 
logic_sector:=rel_sector mod curform. sectors_per_track; 
track :=logic_track+curform.first_pascal_t rack; 
skew:=logic_track*curform.track_skew; 
calc_sect ; 
end; 
end {convert) ; 

begin 

setdisk C drive ! ; 
partial :=false; 
convert; 
dskstrt; 

settrak ( track ) ; 
while length>0 do 
begin 

retry :=max_retry; 
if track>curform.tracks_per_disk 
then begin 

iorslt:=i_ill_block; 
goto 99; 
end; 
if (length<curforin.bytes_per_sector> and read_disk 
then begin 

partial:=true; 
stackbaselO) :=0; 
stackbase[ll :=0; 

setbuf r ( sector_buffer , 0, stackbase ) ; 
end 
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else setbuf r ( buffer, index, baseaddress ); 
setsect t sector ) ; 
10: 

pollunits; 

if read_disk then iorslt:=dskread 
else iorslt :=dskwrit; 
if iorslt<>i_no_error 
then begin 

if iorsltoi_bad_block then goto 99; 
if retry=max_retry 
then begin 

iorslt:=dskinit; 

if iorslt=i_no_unit then goto 99; 
end; 
retry :=retry-l; 
if retry>0 then goto 10; 
goto 99; 
end; 
if partial 
then begin 

{Note: when copying partial sector buffer, destination 
address also includes "baseaddr" which is not shown below} 
moveleft { sector_buf fer -pb" [0] , buffer .pb" [index] , length ) ; 
goto 99; 
end; 
index: =index+cur form. by tes_per_sector ; 
length :=length-curform.bytes_per_sect or ; 
logic_sector :=logic_sector+l; 
if log ic_sect or >=cur form. sect or s„per_t rack 
then begin 

skew:=skew+curform.track_skew; 
track:=track+l; 
settrak ( track ) ; 
logic_sector :=0; 
end; 
calc_sect; 
end {while length>0); 
99: 

dskstop; 

disk_rw: e iorslt; 
end {disk_rwl ; 

Function bios_dsk_read{ block: integer; length: integer ; buffer :p_memory ; 

index , dr ive : integer ; control : rwct rl ; 

codepool:f ulladdress ) :iorsltwd} ; 
begin 

bios_dsk_read:=disk_rw( block, length, buffer, index, drive, control. 



end; 



Function bios_dsk_write{ block : integer ; length : integer ; buf f er :p_memory ; 

index, dr ive: integer ; control :rwctrl ) :iorsltwd) ,* 
var baseaddr :f ulladdress; 
begin 

baseaddr [0] :=0; 
baseaddr 111 : a 0; 

bios_dsk_write:=disk_rw( block, length, buffer, index, drive, control , 
baseaddr, false ) ; 
end; 

Function bios_dsk_init { drive:integer ):iorsltwd}; 
begin 

setdisk ( drive ) ; 

dskstrt; 

bios_dsk_init : "dskinit ; 

dskstop; 
end; 

Function bios_dsk_stat{ drive:integer ; var status:statrec; 

control :statctrl ) : iorsltwd) ; 
begin 

setdisk C drive ); {setdisk might call disk_changej 

status [0] :=0; 

status II] :=curform.bytes_per_sector ; 

status [2 J : =cur form. sect or s_per_t rack; 

status [31 :«curform.tracks_per_disk; 

bios_dsk_stat:=i_no_error; 
end; 
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Function bio»_reni_read{ var ch:char J:iorslfcwd}; 
begin 

ch:=q_get( rem_queue ); 

bios_rem_read:=rem_queue.iorslt; 
end; 

Function bios_rem_write{ chrchar ):iorsltwdJ; 
begin 

pollunits; 

bios_reai_write:=remwrit ( ch ); 
end; 

Function bios_rem_initf :iorsltwd} ; 
begin 

q_init t rem_queue ) ; 

rem_queue.ringbell:=false; 

bios_rem_init:=reminit ; 
end; 

Function bios_rem_stat { var status:statrec; controlistatctrl ):iorsltwd}; 
begin 

pollunits; 

if control. io_direction=input_status 
then status [0] :=q_count ( rem_queue ) 
else statusCO] :=0; 
bios_rem_stat:=rem_queue,iorslt; 
end; 

Function bios_usr_read{ block: integer; length : integer ; buffer :p_jnemory; 

index, device: integer; control irwctrl ) ;iorsltwd} ; 
begin 

bios_usr_read;=usrread( block, length, buffer, index, device, control ); 
end; 

Function bios_usr_write{ block : integer ; length: integer ; buf fer :p_memory; 

index, device: integer: control :rwctrl ) :iorsltwd} ; 
begin 

bios_usr_write:=usrwrit ( block, length, buffer, index, device, control ) ; 
end; 

Function bios_usr_init { device: integer ) : iorsltwd} ; 
begin 

bios_usr_init :=usrinit ( device ); 
end; 

Function bios_usr__stat { device:integer; var status:statrec; 

controlistatctrl ) tiorsltwd}; 
begin 

bios_usr_stat :=usrstat ( device, status, control ); 
end; 

Function bios_sys_readt block : integer ; length: integer ; buf fer:p_jnemory; 

index, device: integer; control:rwctrl ):iorsltwd>; 
begin 

syshalt; 
end; 

Function bios_sys_write{ block : integer ; length: integer ; buffer :p_memory; 

index, device:integer ; control :rwctrl ):iorsltwd>; 
begin 

syshalt; 
end; 

Function bios_sys_init { device: integer ; 

procedure signal_event { event_num: integer } ):iorsltwd}; 
begin 

bios_sys_init :=sysinit ( signal_event , pollunits, disk„change ); 
end; 

Function bios_sys_stat { var status:statrec; controlistatctrl ):iorsltwd}; 
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begin 

status [0 J :=hi_addr.i; 

bios_sys_stat:=clkread ( status [23 , status [1] ) ; 
end; 

Procedure bios_quiet; 
begin 

quiet; 
end; 

Procedure bios_enable; 
begin 

enable; 
end; 

Function bios_ser_read{ device: integer ; var ch:char ):iorsltwd>; 
begin 

bios_ser_read:=i_no_unit; 
end; 

Function bios_ser_write{ device: integer ; ch:char ) :iorsltwd}; 
begin 

bios_ser_write:=i_no_unit ; 
end; 

Function bios_ser_init { device: integer ):iorsltwd}; 
begin 

bios_ser_init:=i_no_unit ; 
end; 

Function bios_ser_stat { device: integer ; var status:statrec ; 

control:statctrl ):iorsltwd}; 
begin 

bios_ser_stat :=i_no_unit; 
end; 

End {BIOS}. 
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GLOSSARY 

This specialized glossary is intended as an aid to 
readers who are unfamiliar with some of the terms 
used in this document. It isn't meant to be 
comprehensive. 

ASSOCIATE TIME - That part of a program's 
lifetime in which the segments and their various 
references to each other are associated by the 
operating system. This occurs when the program is 
prepared for execution. 

BLANK-FILLED - All 8-bit bytes within the 
specified region are filled with blanks (ASCII 32). 

BLOCK — An area of memory (usually on a disk) 
with a fixed size of 512 contiguous 8-bit bytes (256 
contiguous 16 bit-words). 

BLOCK BOUNDARY - Byte zero of any block. 

BYTE POINTER - A byte address (as opposed to 
a word address). 



BYTE SEX — Some processors address 16-bit words 
with the most-significant-byte first, others with the 
least-significant-byte first. Byte sex refers to this 
difference in addressing; two machines with 
different addressing styles are said to have 
different (or opposite) byte sex. 



A-28 0400101:0AA 



Appendix G 



COMPILATION UNIT - A program or portion of a 
program that can be compiled by itself— in other 
words, a program or a UNIT. 

COMPILE TIME — That part of a program's 
lifetime in which it is being compiled (or 
assembled). 

CONCURRENCY - The execution of two or more 
tasks or processes in parallel; that is, at the same 
time. Synonymous with multitasking. 

DYNAMIC — Information which changes during 
program execution (or isn't known before run-time). 

FILLER — A field in a data structure that is at 
present unused. If this area is described as 
"reserved for future use," then it usually should be 
zero-filled. This avoids confusion when future 
versions of the system make use of filler space. 

INTERSEGMENT - The data (or program) in 

OUestion OCCUDies more thfln nne spcrmont np 
■• — o > —* 

contains pointers to another segment. 

LINK TIME - That part of a program's lifetime in 
which it is being operated on by the linker. 

MULTIPROGRAMMING - An environment that 
supports more than one user, where each user can 
perform multitasking. (The p-System doesn't 

support multiprogramming.) 
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MULTITASKING — The execution of two or more 
tasks in parallel; that is, at the same time. A task 
is a PROCESS from your point of view; from the 
system's point of view it might be a program. (The 
p-System does support multitasking.) 

MULTIWORD — Some positive integral number of 
words. 

NATIVE CODE — Assembled code for some 
physical (as opposed to ideal) processor. Also 
called machine code or (sometimes) hard code. 

ONE'S COMPLEMENT — All bits in the designated 
field are flipped. 

P-CODE — Assembled code for an ideal processor. 
P-code stands for "pseudo-code." The p-System 
PME implements a "pseudo machine emulator." 

POSTPROCESSOR — A program which is executed 
after the completion of some other program, and 
uses as input the output of that previous program. 
A postprocessor that creates output which can be 
used by still another program is often called a 
"filter." 

PRINCIPAL SEGMENT - A segment that has a 
segment reference list; for example, a segment with 
a SEG_TYPE of PROG_SEG or UNITSEG. 
Corresponds to the outer segment of any 
compilation unit. UNITs, FORTRAN programs, and 
the outermost block of a Pascal program are all 
principal segments. 
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RELOCATABLE - A portion of object code that 
can be moved to different locations in memory 
without changing its meaning. P-code is 

relocatable. Native code may or may not be. 

RUN-TIME - That part of a program's lifetime in 
which it is being executed (or "run"). 

SELF-MODIFYING - Code which overwrites or 
modifies itself during execution, thus changing its 
meaning. This isn't recommended! 

SEG-RELATIVE - The address of an object is 
specified as an offset from the beginning of the 
code segment in which it resides. 

STATIC — Information which doesn't change 
throughout program execution (it is known before 
run-time). 



SUBSIDIARY SEGMENT - A segment that has no 
segment reference list; for example, a segment with 
a SEGTYPE of PROCSEG or SEPRT_SEG; 
Corresponds to the object code of any segment 
whose source text is not separately compilable. 
Pascal segment procedures and segments produced 
by the UCSD adaptable assembler are subsidiary 
segments. 

TOS - Short for "top of stack." Also represents 
the object that is on the top of the p-machine 
stack (which is the object that was most recently 
pushed). 
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UPWARD COMPATIBILITY - Code that runs on 
current versions of a system will run on future 
versions of that system. A more limited and more 
easily obtained version of upward compatibility 
requires source code to be recompiled on new 
versions, but ensures that it will run when 
recompiled. 

WORD — Sixteen bits aligned on an even 
byte-address boundary. The byte which is most 
significant is determined by the byte sex of the 
machine for which it was generated. 

WORD POINTER — A word address (as opposed to 
a byte address). The address of a word must be 
even. 

ZERO-FILLED — A field of data that contains 
nothing but zeroes (all bits must be 0). 
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